RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
On Wed, 18 Jun 2008, Zhenbin Xu wrote: In the case there isn't clear technical differences, I don't think we should pick the right solution based on implementer's cost. Rather We should base it on customer impact. A bank with 6000 applications built on top of IE's current APIs simply would not be happy if some applications cannot run due to changes in some underlying object model. And this is not IE's problem alone since the bank simply cannot upgrade or change the browser, if all other browsers result in the same breakage. For non-Web HTML pages like in this example, solutions like IE's IE7 mode are fine. IMHO we should be concentrating on pages on the Web, not on browser-specific pages -- interoperability isn't relevant when the page isn't intended to run on multiple browsers. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
On Tue, 17 Jun 2008, Zhenbin Xu wrote:
I am not sure if I understand your question. responseXML.parseError
has the error information
http://msdn.microsoft.com/en-us/library/aa926483.aspx
Oh, I assumed Sunava meant a conforming Document object was returned.
A parseError-type object would be what I had in mind, yes. However, if
we do this, then we should specify it. If we don't specify it, I'd
rather have an exception.
The spec can simply state that a conforming document object is returned,
which includes out-of-band error information. This is what IE does today
and is a very reasonable approach that allows rich error information for
debugging.
I don't believe it is conforming for Document objects to have parseError
attributes, but I could be mistaken -- is there a spec for parseError?
Even if there isn't, though, I agree that it is a generally good solution
to the problem, I'm just saying that we should specify it, so that UAs
can be standards-compliant and support it interoperably.
Not really; if the script is expecting an exception, and receives null
instead, then they'll just get an exception as soon as they
dereference the object, which in almost all cases will be straight
away.
[Zhenbin] I should explain the scenario I talked about. For instance, if
I am to write a wrapper object myXHR, it makes a difference for me when
I do the following
myXHR.responseXML
if (!_innerResponseXML)
{
try
{
_innerResponseXML = _innerXHR.responseXML;
}
catch (e)
{
_myexception = e;
return _dummpyResponseXML;
}
}
return _innerResponseXML;
My try catch would not catch null. And the exception would be passed on
to my callers, which is not what I wanted.
Indeed.
If we are going to spec it to accommodate all existing browsers, we
would want to make it return null or INVALID_STATE_ERR exception.
We want interoperable behaviour, so defining it in this way would be a
bad idea. (I don't really have an opinion either way about exception
vs null, but it seems that we should just pick whatever is most
commonly implemented, which I'm guessing is what Anne did here.)
Fair enough. So let's pick one.
What is commonly implemented? Is it largest browser market share?
Since the cost to implementations for fixing the problem is independent of
the size of the user base, it would be based just on the number of
independent implementations.
Is it number of enterprise applications written on top of particular
browser?
All the browsers want to be compatible with the Web, so if there are mroe
Web sites depending on the exception behaviour than the null behaviour,
then we clearly should do the exception behaviour. And vice versa. Do we
have any good numbers on this? (That there are widely deployed browsers
that return null instead of throwing an exception tends to suggest that
Web pages don't depend on either behaviour; we'd probably need evidence
to the contrary to decide one way or the other based on compatibility.)
Is it the number of browers, in which case I hope my fictional
home grown personal browser gets a vote :-)
Obviously fictional browsers aren't relevant, since the cost of fixing a
fictional browser is zero.
From a pure technical point of view, predictably throw exception on
state violations is easier to understand. I hope you would agree there
is value to change spec for the sake of consistent programming model
(which happens to be the IE model).
Indeed.
Did the spec call out that responseXML returned from XHR should have
equivalent DOM support as UA's object? If it is, that would be a good
topic for us to debate about.
I believe the spec just says that you return a Document object; it is the
lack of a distinction between different Document objects that requires the
level of support to be the same. As you said, a consistent programming
model has value.
I disagree that because DOM Level 3 is 3+ yr old spec that every UA has
to support it in order to be XHR compliant, if that is what you implied.
I didn't mean to imply that. I don't think XHR should require any
particular level of support.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
On Sun, 15 Jun 2008, Zhenbin Xu wrote: Ian wrote: On Wed, 11 Jun 2008, Sunava Dutta wrote: When Parsing Error happens, IE would still retain responseXML and put error information on the object. Isnt this better than null as there�s more relevant information for the web developer? How does one distinguish a document returned with parse error information from one that happens to look like a parse error but was well-formed? I wouldn't mind including more information but it seems like it should be out-of-band. I am not sure if I understand your question. responseXML.parseError has the error information http://msdn.microsoft.com/en-us/library/aa926483.aspx Oh, I assumed Sunava meant a conforming Document object was returned. A parseError-type object would be what I had in mind, yes. However, if we do this, then we should specify it. If we don't specify it, I'd rather have an exception. The test is expecting us to return NULL in case open() has not been called. We throw an exception in IE. I�d pre fer if the spec says �MUST return null OR an exception� otherwise I fear sites today will be broken. If a site is expecting an exception and gets null, then they'll get an exception when they try to dereferene the null, so in most cases it seems like this would work anyway. Properly written sites would have no problem one way or the other. However if someone is writing a wrapper on top of XMLHTTP, clearly it would make a difference on how to expose wrapped properties. Not really; if the script is expecting an exception, and receives null instead, then they'll just get an exception as soon as they dereference the object, which in almost all cases will be straight away. If we are going to spec it to accommodate all existing browsers, we would want to make it return null or INVALID_STATE_ERR exception. We want interoperable behaviour, so defining it in this way would be a bad idea. (I don't really have an opinion either way about exception vs null, but it seems that we should just pick whatever is most commonly implemented, which I'm guessing is what Anne did here.) I think it's important that we test that the DOM returned from XHR is DOM Core conformant just like any other, so this seems like an important and relevant testing area for XHR. That is not necessarily a good idea because you would then have to mandate which level of DOM Core support is required. And if the spec requires DOM level 3, that is big barrier for new user agent that wants to be compliant with XHR spec. getElementById requires DOM Level 2. At the least the testing case can be changed to use getElementByTagName, which is DOM level 1. I think expecting DOM Level 3 is the least of our worries -- after all, that's a 3+ year old spec. So testing just DOM Level 2 is really not a problem as far as I can tell. However, I agree that it would make sense to make the test pass if the UA didn't support that level of DOM on regular DOM objects too. The key is just to make sure that the objects returned by XHR are of equivalent DOM support as the rest of the UA's objects. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: Seeking earlier feedback from MS [Was: IE Team's Proposal for Cross Site Requests]
On Wed, 11 Jun 2008, Sunava Dutta wrote: Try this link instead: http://code.msdn.microsoft.com/xdsecuritywp Could you forward the paper to the list? (Preferably as plain text, though HTML or PDF would do in a pinch.) It's not clear to me whether the paper on that site is actually covered by the license on that page, and I don't really want to run the risk of committing Google to a license by accident without speaking to our lawyers first, and that seems like a bit of an extreme to go to just to see your feedback. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Further LC Followup from IE RE: Potential bugs identified in XHR LC Test Suite
Some quick comments on some of the comments regarding the tests: On Wed, 11 Jun 2008, Sunava Dutta wrote: http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/009.htm When Parsing Error happens, IE would still retain responseXML and put error information on the object. Isnt this better than null as there�s more relevant information for the web developer? How does one distinguish a document returned with parse error information from one that happens to look like a parse error but was well-formed? I wouldn't mind including more information but it seems like it should be out-of-band. http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/001.htm The test is expecting us to return NULL in case open() has not been called. We throw an exception in IE. I�d pre fer if the spec says �MUST return null OR an exception� otherwise I fear sites today will be broken. If a site is expecting an exception and gets null, then they'll get an exception when they try to dereferene the null, so in most cases it seems like this would work anyway. http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/012.htm http://tc.labs.opera.com/apis/XMLHttpRequest/responseXML/013.htm This test really doesn�t test XHR here. It seems to be focused on manipulating the XML DOM. (I also don�t think Microsoft.XMLDOM supports getElementById for an XML document FYI). Also, if I'm barking up the wrong tree here please let me know! I think it's important that we test that the DOM returned from XHR is DOM Core conformant just like any other, so this seems like an important and relevant testing area for XHR. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Transitioning to WebApps Mailing List
On Tue, 10 Jun 2008, Doug Schepers wrote: As for being subscribed to a list without being asked... I don't know. Just position it as a list renaming. :-) Then they're aren't being subscribed to a new list, so much as having an existing subscription updated for their convenience. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Proposed errata for DOM2 Range regarding insertNode()
Chaals, please see the end of this message. On Wed, 28 May 2008, Jonas Sicking wrote: It seems to me that everyone agrees that insertNode() was always intended to insert a node _into_ the range, and that the collapsed case was simply lost between the cracks when the DOM WG was writing the spec (much as was interaction with mutation events, for instance). Everyone who? And based on what? I don't see anything in the spec that suggests that. And as Olli pointed out there is clearly language in the spec that indicates that the inserted node would be after the range in the collapsed case. Well, everyone except you and Olli apparently. :-) Do you really think that it was intended for insertNode() to act differently when the range was collapsed than when the range wasn't collapsed, with respect to whether the inserted node ends up in the range or not? I guess I'm fine with making the change to the spec, but it would be a change and not an errata. I'm not sure what the distinction is. And if we're making changes anyway, I would requests that we make NodeIterators behave like TreeWalkers as far as the returnvalue for the NodeFilter goes. That is both more useful and easier to implement since it allows more code reuse. I recommend putting this forward as a separate errata. I only suggested this one because implementations seem to be differing on how to implement that part of the spec, and it seemed like it would be worth having a cycle that didn't require finding an editor to resolve the problem. On the long term I do think we need to get Traversal Range rewritten with strict conformance requirements in mind. On Thu, 29 May 2008, Olli Pettay wrote: The current version of the spec handles dom mutations consistently (whether using node.insertBefore/appendChild or range.insertNode) and that is not something I'd like to lose. This seems like a consistency that would hurt the authors, though. What's the use case for insertNode() inserting after the range? If that is changed, the insertNode part of the following wouldn't be true anymore (2.12): Any mutation of the document tree which affect Ranges can be considered to be a combination of basic deletion and insertion operations. In fact, it can be convenient to think of those operations as being accomplished using the deleteContents() and insertNode() Range methods and, in the case of Text mutations, the splitText() and normalize() methods. Indeed. I do think that the spec intended the behaviour that I am proposing we clarify in errata, though I agree that it could be read otherwise. I honestly don't see any reason for the behaviour you advocate, it seems confusing, not useful, and not in line with the intent of the spec. However, I'm not sure how to make further progress if you disagree to this change. It would be helpful if we could get a working group decision on this so that I could know whether the Acid3 test should be changed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Geolocation ideas
On Thu, 5 Jun 2008, Charles McCathieNevile wrote: Could you please confirm that it is acceptable for us to begin unofficially discussing geolocation API requirements on the public-webapi@w3.org mailing list and for us to start noodling on ideas in CVS in the http://dev.w3.org/cvsweb/2006/webapi/ directory? We would like to start today. I cannot stop you doing it. On the other hand, given that there is an existing mailing list and that you have been explicitly asked to use it for the topic it was set up for, it seems a bit small-minded not to do so. Okie dokie. We'll use the public-geolocation list. Happy birthday, btw. :-) On Thu, 5 Jun 2008, Doug Schepers wrote: Matt Womer set up a (temporary?) playground to submit geolocation API documents for discussion: http://dev.w3.org/geo/ and http://dev.w3.org/geo/api Cool, we'll use that. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [web forms 2]Behavior of maxlength on scripted value changes
On Thu, 5 Jun 2008, Boris Zbarsky wrote: The section on maxlength in http://www.whatwg.org/specs/web-forms/current-work/ (the 12 October 2006 version) says nothing about what happens if script on the page (or script from a bookmarklet, whatever) does: myInput.value = some long string; where the string length is longer than myInput.maxlength. The spec scatters the definitions around a bit (this will be solved when WF2 is merged with the rest of HTML5, and is a legacy of the diff design of the spec as opposed to a self-contained spec) but actually this is defined in the DOM section: # Setting a control's value DOM attribute dynamically in such a way that # it makes the control invalid because the value doesn't conform to the # attributes setting constraints on the value, however, must cause the # control to be set to the new value, and the control becoming invalid. # (For example setting the value of a text control to a string that is # longer than the maxlength attribute specifies would set the control to # that long value, but then prevent submission.) (Note that the prevent submission thing is new behaviour due to the client-side validation in WF2. If this turns out to be incompatible with the Web, we'll have to change it somehow, maybe by keeping track of whether the value was set by script or not.) HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Dedicated Geolocation List and Channel
On Mon, 2 Jun 2008, Doug Schepers wrote: Matt Womer and I have started a new email list for discussing geolocation. The new list, public-geolocation [1], will be archived, and the intent is for it to be the public list for the planned Geolocation WG: http://lists.w3.org/Archives/Public/public-geolocation/ I want to encourage folks not to put off technical discussion on the matter, or wait for the Geolocation WG to form; you can join the email list today, and start your engines. Of particular interest will be initial discussions of what the scope of the deliverables should be, and that will affect the charter. Could we please keep the discussion to this group? It seems like most people on this group agree that the work should happen in this group, and it would be very confusing to have to move stuff back and forth, especially if the charter proposal for geo fails, as seems likely given several browser vendors have requested that it stay in this group. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XHR review extension
On Tue, 3 Jun 2008, Doug Schepers wrote: I think I would rather just move on given how long the review period has been and how long we've been working on XMLHttpRequest Level 1, but that shouldn't preclude the SVG WG from providing feedback later on. Noted. But this is not an editorial decision, it is a WG decision. I don't see the harm in extending the LC period for a week or two: the test suite is not done; there is no urgent release cycle for implementations coming up; and the plan is to simply park this in CR until HTML5 is more mature. So, I propose we honor this request. If I'm missing some particular urgency, I'm happy to reconsider my two cents. Google supports the editor's opinion that we should not continue delaying publication given that the last call for comments was sent out in April and that the draft originally entered Last Call over a year ago. In particular, it is time to send implementors the message that the spec is ready to be implemented, especially given how XHR1 is effectively a basis for our extensions in XHR2, and how XHR2 has suffered innumerable delays in the past few months. However, that isn't to say that we should ignore the SVGWG's feedback. In practice I don't see how it makes any difference which level the spec is in -- if we receive feedback we should fix the spec either way. It is unlikely that the SVGWG would send feedback that requires substantial changes, since XHR1 is mainly aimed at describing existing behaviour. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Geolocation ideas
Hey Chaals, Could you please confirm that it is acceptable for us to begin unofficially discussing geolocation API requirements on the public-webapi@w3.org mailing list and for us to start noodling on ideas in CVS in the http://dev.w3.org/cvsweb/2006/webapi/ directory? We would like to start today. If yes, then could you maybe please also confirm that the working group will adopt geolocation APIs as a working group work item, at least until the W3C has decided whether to create a new working group for this? As far as I can tell no working group members has expressed their dissent and several have expressed their agreement since I first mentioned this last week, which puts us ahead of most of our working group decisions! :-) I understand that you are travelling; my apologies for making this request when you are indisposed. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Event handler attributes (Was: Dependencies in XHR)
On Tue, 27 May 2008, Doug Schepers wrote: We have discussed adding consideration for event handler DOM attribute in the DOM3 Events spec, such that a host language can define what that means in its context That would be great, I'd love to offload this part of HTML5. Do you have a plan for how to resolve the dependency between event handler DOM attribute processing and the designMode DOM attribute? Also, please remember to deal with the mouseover event's quirk when doing this. (This seems like a sarcastic and combative reply, for no good reason.) Sorry, that was not the intent. Perhaps I misunderstood the issue. My impression was that Anne was referring to the definition for the onfoo event handlers, as stated in the HTML 5.0 spec: Event handler DOM attributes, on setting, must set the corresponding event handler attribute to their new value, and on getting, must return whatever the current value of the corresponding event handler attribute is (possibly null). Right, that is indeed what I'm talking about (that and the event handler content attributes). I really would like this to be taken out of HTML5 and turned into a generic mechanism. A host language, such as HTML or SVG, would define the specific event handler attributes appropriate to that language, and provide details about the event. The host language would also cover the particulars of the quirks you mention (so, sorry, but you're stuck with that task). designMode's quirks aren't HTML-specific, they apply equally to SVG event handlers. I expect (but haven't tested) that the same applies to onmouseover's quirks. I certainly would rather all the behaviour was defined in one place than requiring implementors to have to cross-reference multiple specs to get this done right. (In particular, I think we really need to get over the concept of but that's a host language issue or that doesn't belong in my spec and so on -- we're defining a single platform here, it isn't useful for us to be declining responsibility over the more complicated parts. While the theory of orthogonal technologies would have been nice, the Web is at a point where all the technologies are embedded in each other to some extent, and we should embrace that, not try to deny it. We will have a healthier technology stack if we consider the HTML and SVG specs, say, to be different chapters of the same language spec, rather than if we consider them to be separate languages.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Proposal to work on Geolocation
Hi, Google would like to volunteer some resources to work on a specification to provide a Geolocation API for the Web platform. Does anyone on the working group think we should not work on this? If not, please consider this a formal proposal from us to adopt a Geolocation API as a work item. Since we need broad working group agreement to add a work item, I propose that we set a deadline of June 4th for dissent, though as Chaals always says, positive assent would be preferred. :-) Chaals, could you do the honours of making this formal? Thanks! Background: http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0011.html http://code.google.com/p/google-gears/wiki/GeolocationAPI Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Proposal to work on Geolocation
On Tue, 27 May 2008, Doug Schepers wrote: The W3C intends to follow through on that, and to allocate Team resources to this valuable technology. We will announce something formal soon. Rest assured that Mike and I are intent on ensuring that there is no scope creep for this API, and that the Geolocation API WG will take a pragmatic, vendor-aware approach, and will act quickly. Sure, the proposal to work in the Web API working group is only intended to be a stop-gap measure while we wait for the wheels of the W3C to turn. It would be sad to delay this while we wait for charters to be written and so forth. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Proposal to work on Geolocation
On Tue, 27 May 2008, Doug Schepers wrote: I want to reiterate that W3C is *not* dropping the Geolocation API... we merely propose to move it to a dedicated WG. [...] Again, we are actively encouraging all interested parties to join this new Geolocation WG, and we will expedite its creation as far as we can. Do you know when the AC review for this new WG will start? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Proposal to work on Geolocation
On Tue, 27 May 2008, Doug Schepers wrote: Again, we are actively encouraging all interested parties to join this new Geolocation WG, and we will expedite its creation as far as we can. Do you know when the AC review for this new WG will start? Not at the moment, but we are looking into it aggressively. I'll keep you posted as we make progress. Cool, thanks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Proposal to work on Geolocation
On Tue, 27 May 2008, Doug Schepers wrote: Ian Hickson wrote (on 5/27/08 6:09 PM): On Tue, 27 May 2008, Doug Schepers wrote: The W3C intends to follow through on that, and to allocate Team resources to this valuable technology. We will announce something formal soon. Rest assured that Mike and I are intent on ensuring that there is no scope creep for this API, and that the Geolocation API WG will take a pragmatic, vendor-aware approach, and will act quickly. Sure, the proposal to work in the Web API working group is only intended to be a stop-gap measure while we wait for the wheels of the W3C to turn. It would be sad to delay this while we wait for charters to be written and so forth. That's a very reasonable concern. Since we are hoping for the WebApps WG to be chartered as soon as we hear back from the AC reps (hopefully a couple of weeks or less), it may not be appropriate to do it here... To clarify, we do consider two weeks to be a wait. To be honest we're worried that with vendors already working on products that do Geolocation stuff, we may have waited too long already. The sooner we can get people together to discuss this the better. In fact, would it be possible to unofficially use this mailing list to discuss proposals while we wait for a formal decision from Chaals on whether Geolocation can (even temporarily) be a WebAPI work item? Regarding proposed deliverables in general, I've provided a mechanism for that which I hope will be more agile, while providing due oversight... rather than rechartering the WG, we can merely present a proposal to the AC (based on initial use cases, requirements, research, etc.), and formally add it to our list of deliverables upon approval. I anticipate steady progress in this group, so as we free up resources, we should keep looking forward for useful things that we can work on. FWIW, the resources Google has to offer here aren't locked to working groups, they're locked to work items. So insofar as Google is concerned, it would make no difference if there was one group or ten, we'd have the same amount of resources. The list of deliverables that matters is the total of all the deliverables we're interested in, not the deliverables that a particular working group is tasked to work on. Having said that, I personally do think it would be wiser to keep all DOM APIs intended for browsers in one working group. The confusion we had with two working groups (WebAPI and WAF) led to us merging them, it would be sad to then immediately forget the lesson we had learnt and split work up again. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: removeRequestHeader()
On Tue, 27 May 2008, Julian Reschke wrote: Anne van Kesteren wrote: FF3 (removing the header) demonstrates that this case (null value) either should be left unspecified, or specified with a more useful behavior. Firefox demonstrates that it is not interoperable with the three other browsers. It does not demonstrate anything about the need to do this differently than currently specified. Setting a header to null, and expecting the header to be sent as null is a bug. You haven't provided any evidence of clients relying on this. Please do not wire bad API design like this into the spec, even if it's common for Javascript APIs. I have to say, I would rather prefer it be treated as . -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Moving forward with XHR2 and AC
On Tue, 27 May 2008, Jonas Sicking wrote: What I suggest is that we prohibit the Access-Control-Policy-Path header from being used on URIs that include the string ..\, in escaped or unescaped form. One worry with this is if there are encodings which put the '.' or '\' characters to other codepoints than 2E and 5C respectively. I.e. would we need to forbid its use on URIs other than ones containing (.|%2e)(.|%2e)(\|%5c) I could live with that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [XHR] Dependencies in XHR
On Tue, 27 May 2008, Doug Schepers wrote: It seems that there are multiple dependencies upon HTML 5.0 in the XHR specification. As Team Contact, I would like to caution against this approach, as the HTML 5.0 specification is a long time from being stable, and this hinders implementation (particularly for vendors who sell their browsers, and must therefore market them). [...] I believe that origin can be defined in the Window Object specification, one of this WG's explicit deliverables. Objects implementing the Window interface must provide an XMLHttpRequest() constructor. Again, see Window Object spec. Um, if we're going to be moving the references away from HTML5, could we at least move them to specs that have a chance of actually getting maintained sometime this decade? We have discussed adding consideration for event handler DOM attribute in the DOM3 Events spec, such that a host language can define what that means in its context That would be great, I'd love to offload this part of HTML5. Do you have a plan for how to resolve the dependency between event handler DOM attribute processing and the designMode DOM attribute? Also, please remember to deal with the mouseover event's quirk when doing this. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Proposed errata for DOM2 Range regarding insertNode()
Since the idea of making it clear that insertNode() inserts the node inside the range even if the range is collapsed seems to have received a somewhat positive response, I'd like to propose the following actual errata text: | DOM Level 2 Traversal and Range | | range-2. 2008-06-... [clarification]. Range.insertNode | | The sentence: | |The node is inserted at the start boundary-point of the Range, without |modifying it. | | Should read: | |The node is inserted at the start boundary-point of the Range, without |modifying the start boundary-point. If the range is collapsed, the |offset of the Range's end boundary-point will be increased so that it |is before the same node or character as it was before the insertion. This uses the language style of the spec as it stands today (we can worry about making the spec use RFC2119 terminology when we rewrite it later; doing that now too would be a big rathole IMHO). Chaals, can we put this to the working group as a proposed errata? On Wed, 14 May 2008, Boris Zbarsky wrote: [discussion regarding mutation event timing] For example regular old insertions and deletions near ranges cause changes to the range values but the spec doesn't say if this is before or after the events. I think it's pretty clear that it should be when the actual mutation occurs (so before the events for insert cases and after for removal cases), but that does mean that one can't implement Range on top of DOM MutationEvents. Then again, there's no much one can implement on top of them, so that's OK, I think. It seems that for sanity we should say it happens before, if we specify this. Should we do this as a separate errata? I just wanted to point out that we have to be very careful in how we phrase this erratum (which I agree is a possibly useful one): we basically want to perform the insertion, then before firing the mutation event adjust the insertion endpoint after all the nodes we just inserted. Or something. In a UA that would fire multiple events here when inserting a DocumentFragment, we might lose no matter what we try to do. I'm not sure what to do about mutation events. I think it may be wiser to punt on this or at least deal with it in a separate errata. On Fri, 23 May 2008, Olli Pettay wrote: So I'm not sure the errata for this issue is actually needed. It seems to me that everyone agrees that insertNode() was always intended to insert a node _into_ the range, and that the collapsed case was simply lost between the cracks when the DOM WG was writing the spec (much as was interaction with mutation events, for instance). While I agree that the spec could be read as saying that the node is inserted after the range when it is collapsed, I don't think we want that behaviour, nor that it was intended. Do you actually think that behaviour is preferred to the insertion behaviour? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XHR LC comments
On Thu, 15 May 2008, Julian Reschke wrote: I don't have an opinion on the exact issue here, but as a general rule I recommend against making decisions based on the political status (rather than technical status) of working groups and specs. Otherwise we just end [up invoking Conway's law] My understanding was that XHR1 is an intermediate step (documenting the current state, and trying to make it more interoperable), while XHR2 would contain something that is really good. If this is the case, it's totally pointless to let XHR1 have normative references on something that won't be finished for a long time. Pragmatically, why does it matter when the references are finished? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XHR LC comments
On Thu, 15 May 2008, Julian Reschke wrote: The spec can't be more ready than all normative references. Sure it can. The concept of origin (for instance) is pretty well understood by browser vendors, and HTML5 is getting progressively closer to defining it. XHR1 doesn't need it to be perfectly defined to make use of it. Same with Window, probably even more so in fact. If these aren't getting ready in time, then I'm not sure why XHR1 needs to be on the W3C REC track at all. Well, personally I don't mind what organisation publishes the spec. The WHATWG would, I'm sure, be happy to publish the XHR spec if the W3C didn't want to do it -- indeed, that's where XMLHttpRequest started its standards career in the first place. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XHR LC comments
On Thu, 15 May 2008, Julian Reschke wrote: Ian Hickson wrote: On Thu, 15 May 2008, Julian Reschke wrote: The spec can't be more ready than all normative references. Sure it can. The concept of origin (for instance) is pretty well understood by browser vendors, and HTML5 is getting progressively closer to defining it. XHR1 doesn't need it to be perfectly defined to make use of it. Same with Window, probably even more so in fact. So why then is the reference to HTML5 needed? Wouldn't you just complain that Window and 'origin' were totally undefined if we used them without referencing something? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XHR LC comments
On Thu, 15 May 2008, Julian Reschke wrote: Ian Hickson wrote: On Thu, 15 May 2008, Julian Reschke wrote: Ian Hickson wrote: On Thu, 15 May 2008, Julian Reschke wrote: The spec can't be more ready than all normative references. Sure it can. The concept of origin (for instance) is pretty well understood by browser vendors, and HTML5 is getting progressively closer to defining it. XHR1 doesn't need it to be perfectly defined to make use of it. Same with Window, probably even more so in fact. So why then is the reference to HTML5 needed? Wouldn't you just complain that Window and 'origin' were totally undefined if we used them without referencing something? That wasn't what I was suggesting. So what are you suggesting? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XHR LC comments
On Thu, 15 May 2008, Julian Reschke wrote: Ian Hickson wrote: ... What's wrong with referencing HTML5? Why can't the spec be more ready than its normative references? We're only really referencing the concept, the details aren't particularly critical to XHR. ... Because, by definition, normative references are part of the specification. But we don't have to limit ourselves to that definition. We could just as easily say that XHR1's functionality is as defined in XHR1, and that it uses terms and features that are currently underdefined. It wouldn't, in practice, take anything away from the ability to get interoperable implemenations of the feature described in XHR1. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: XHR LC comments
On Thu, 15 May 2008, Julian Reschke wrote: But we don't have to limit ourselves to that definition. We could just as easily say that XHR1's functionality is as defined in XHR1, and that it uses terms and features that are currently underdefined. It wouldn't, in ...in which case I'd say that (a) the references aren't normative after all, and (b) the spec itself can't be normative as it is written. I don't mind calling the references informative if that's what it takes. I'm not sure what practical difference it would make. practice, take anything away from the ability to get interoperable implemenations of the feature described in XHR1. Really? What if Apple implements the thing as defined by HTML5-as-of-2008, and Microsoft as defined in HTML5-as-of-2009? If it matters, then it's a problem. If it doesn't matter, leave it out of the XHR spec, as apparently, it's irrelevant for the goal it's trying to achieve. The point is that Apple and Microsoft are both going to implement the thing as required by the Web in 2000, not as defined in HTML5. HTML5 is describing existing practice on these matters, not defining new material. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: XHR LC comments
On Thu, 15 May 2008, Travis Leithead wrote: The point is that Apple and Microsoft are both going to implement the thing as required by the Web in 2000, not as defined in HTML5. HTML5 is describing existing practice on these matters, not defining new material. Well, a _few_ bits of new material ;-) The bits that XHR depend on, which is the subject at hand, aren't new relative to the Web in 2000. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Moving forward with XHR2 and AC
On Thu, 15 May 2008, Sunava Dutta wrote: I expect this to be ready and available to the Web API by mid June in the latest. Cool. Anne, can you summarise what needs doing to XHR2 and AC to move them forwards to last call? Is there a list of outstanding comments anywhere? If there's anything I can do to help I'd be happy to do so. I would like to see this draft reach last call this month if possible. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Proposed errata for DOM2 Range regarding insertNode()
DOM2 Traversal and Range has a number of problems, and really needs a rewrite. However, in the absence of the resources to do that, I realised that we could settle for releasing some errata. Arguably we as a working group have somewhat the authority to do that, so here's a proposal for a simple errata for DOM2 Range. If this works process out well, I'll see if there are other things in DOM2 we should errata sooner rather than waiting for wholesale DOM3 or DOM4 updates. DOM2 Range says of the insertNode() method that A node may be inserted into a Range using the following method. However, if the range is collapsed, according to a strict reading of the specification, calling insertNode() actually inserts the node _after_ the range. I propose that we change the spec to explicitly say that if you call insertNode() on a collapsed range, the end point offset is increased by one, as if the node was inserted before the end point, which I believe to be the intent of the specification. This is implemented by Opera and WebKit already, and is tested by Acid3. If the working group chair will forgive me, I suggest we set a deadline of May 21st (a week from today) at which point if there have been no objections raised we go ahead and make the change to the DOM2 errata. Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Proposed errata for DOM2 Range regarding insertNode()
On Wed, 14 May 2008, Robert Sayre wrote: On Wed, May 14, 2008 at 9:02 PM, Ian Hickson [EMAIL PROTECTED] wrote: As I said in the very first e-mail on this subject, that's what I'd like to do. However, that's a significantly higher cost (years vs weeks) than releasing an errata, and it was my impression that the Mozilla community would like a quick turnaround on this. It looks to me like you're retroactively specifying something in your test. The test verifies that when you call insertNode() on a range, the node that is passed is inserted into the range, as is required by DOM2 range section 2.9. Inserting Content, sentences 1 and 2 (before and after the code snippet). These sentences are contradicted by the more generic sentences in section 2.12.1. Insertions, which don't take insertNode() into account for the case of a collapsed range, and thus end up not implementing the requirement in the former section. I hold that the intent of the spec is clear, in that it would be pretty dumb for an API for inserting nodes into a range didn't actually insert nodes into a range; however, I agree that it is possible to interpret the spec in a way that assums that the generic rules in the latter section override the statements in the former section, hence my proposal that we raise this as an errata. If there is disagreement about a change to normative behavior, it seems like the right thing to do would be to discuss it, not pick one interpretation and try to jam it through as errata. Right, that's why I raised on the list, so that we can discuss it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Progress Events: heads-up regarding begin vs loadstart in HTML5
FYI, I just changed the HTML5 spec to use 'loadstart' instead of 'begin' for the first ProgressEvent. It turns out the reason I used 'begin' is that an older version of Progress Events used 'begin', and this was changed without me noticing. Is there a place where I can track what feedback has or hasn't been responded to regarding Progress Events? In particular, the feedback in: http://lists.w3.org/Archives/Public/public-webapi/2008Feb/0178.html ...doesn't seem to have received a reply, but I can't tell if it is still in the queue or if it was dropped somehow. Is there some process by which I should raise issues to make sure they don't get lost? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)
On Tue, 13 May 2008, Maciej Stachowiak wrote: On May 13, 2008, at 5:08 AM, Charles McCathieNevile wrote: (I suspect that if we are still relying on a thing called 'blob' because we still don't have real file system access with some sense of security by the time we want to hand around a Terabyte in a web application, that we will have seriously failed somewhere. Although it isn't impossible that we end up there). I see no reason the Blob proposal couldn't handle uploading a Terabyte of data. 2^53 10^4. Indeed, for data that large you really do want a filesystem reference that you can hand directly to a network API so it can be sent without having to load the whole thing into memory via script. Indeed. I should add that while many users aren't necessarily there yet, there are environments (e.g. within Google) where dealing with multi-terabyte files is a pretty regular occurance. We certainly have a vested interest in making sure that the Web APIs can handle this amount of data -- this is the kind of thing we'd be using now, if we could. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [selectors-api] Proposal to Drop NSResolver from Selectors API v1
On Mon, 12 May 2008, Maciej Stachowiak wrote:
A function is not a particularly convenient way to specify a namespace
mapping, and it creates these error handling issues as well as causing
problems with case (in)sensitivity. Even though NSResolver is what XPath
uses, wouldn't it be simpler to just accept an object that provides the
relevant namespace mappings? I originally thought that this could be a
JSON-style JavaScript object, but it seems to me that a DOM node would
actually work just as well.
How about a dedicated object?
var namespaces = new NamespaceMapper();
namespaces.add('xhr', 'http://www.w3.org/1999/xhtml');
namespaces.add('svg', 'http://www.w3.org/2000/svg');
...and then you can just pass this lightweight object around.
[Constructor] interface NamespaceMapper {
void add(in DOMString prefix, in DOMString namespace);
};
This also resolve the case problem, as we can just define it to be
case-folding in some specific way that we control. We don't need to allow
namespace prefixes to be removable, mutable, or enumerable, either, this
can be a completely opaque object, thus allowing UAs to apply whatever
fancy one-way hashing algorithms they want for performance.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: IE Team's Proposal for Cross Site Requests
but the server sniffs it as an HTML file and sends it back as such). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)
On Sun, 11 May 2008, Charles McCathieNevile wrote: Do we have the resources to have someone champion this spec? Are you asking the WG, or Google? The Web community as a whole. I don't care which working group (if any) owns it, and I don't have any reason to prefer that Google work on this rather than anyone else -- my interest is in forwarding the platform as a whole. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Blobs: An alternate (complementary?) binary data proposal (Was: File IO...)
On Wed, 7 May 2008, Aaron Boodman wrote: Charles wrote: Opera has a proposal for a specification that would revive (and supersede) the file upload API that has been lingering so long as a work item. I would echo the other comments people have made regarding the security model being the important aspect of this kind of area. The Gears team has also been putting together a proposal for file access which overlaps in some ways with Opera's, but is also orthogonal in some ways: http://code.google.com/p/google-gears/wiki/BlobWebAPIPropsal I do like the general approach here. I especially like the way that it combines the Mozilla extensions with a generic mechanism that applies across multiple APIs. I'm not sure I like the way that the bytes are made accessible, but that's a minor detail really. (In particular, I'd like to see plain text APIs to treat a blob according to a particular encoding.) This seems like it would be something we may want defined in a small spec and then used by many others (like progress events) -- one spec to define Blob, and then the other specs to use it (like XHR and HTML5/WF2). Do we have the resources to have someone champion this spec? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: specification of legacy key events
On Thu, 8 May 2008, Maciej Stachowiak wrote: We have had requests to fire some kind of identifiable event when typing occurs during IME processing for use cases like the following: 1) To resize an area based on user typing, even during IME entry (yes, this works right, the text is in the text field even when unconfirmed.. 2) To have special keyboard shortcuts work in a text field even during IME entry. Indeed, we (Google) would very much like our scripts to be notified of what's going on, keyboard-wise, during IME. In particular when the user is working with a contentEditable section we really need to have access to these events so that, for example, we can, if the user so desires, cancel them and provide our own IME implementation (which might hook into user-specific information that the UA might not be able to provide). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: IE Team's Proposal for Cross Site Requests
On Tue, 29 Apr 2008, Chris Wilson wrote: On Wed, 23 Apr 2008 10:01:33 +0200, Anne van Kesteren wrote: On Wed, 23 Apr 2008 04:26:39 +0200, Sunava Dutta wrote: I think this discussion is best continued in a telecon. Wouldn't it be better if the IE Team first addressed the issues raised so far with XDomainRequest in an e-mail? Getting this information in a teleconference is not very convenient as minutes are often of poor quality and teleconferences don't allow for thinking arguments through and studying them. Here's a subset of the e-mails that as far as I can have not been addressed by the IE Team: http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0211.html http://lists.w3.org/Archives/Public/public-webapi/2008Mar/0212.html http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0125.html http://lists.w3.org/Archives/Public/public-webapi/2008Apr/0056.html Given the multitude of issues raised, and the obvious back-and-forth that denotes many differing opinions, I'd suggest having a telecom to discuss these questions, and make sure that Sunava, Eric and myself can attend. I'm with Anne on this. Please reply to the e-mails before convening a telecon. It is very difficult to carefully consider feedback in the context of a telecon. The problem isn't back-and-forth denoting many differing opinions, the problem is that we don't know what Microsoft's opinion _is_. Telecons are by their nature much less open, and minutes are almost uniformly so poor that it is hard to impossible to get precise technical details out of telecons. A telecon would not be appropriate at this point. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: Modal dialogs in HTML5
On Tue, 29 Apr 2008, Travis Leithead wrote: Most modality discussed so far has been about the view modality, ie disallowing the user from accessing the original page content until the dialog has been dismissed. Browser modality may also be about not letting the browser unload/reload the page until a dialog has been dismissed (eg do you want to save before closing the window?). Is there any way to force a user to respond to a modal dialog section before unloading the page? If not, ideally a generic modality feature could be added to assist both sections and current style HTML dialogs in achieving this unload modality. I'm not a big fan of allowing a web application to have that level of control of a user's browsing experience (a web page preventing a user from closing a tab, for example). The desktop paradigm is like allowing a program to prevent the user from restarting or shutting down the OS--seems like a bad design decision. I totally agree. Please invent a time machine and go back to Microsoft about 10 years ago and tell them not to invent showModalDialog(). :-) At this point, browsers have to support it, there's too much content out there that uses it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Modal dialogs in HTML5
On Fri, 27 Apr 2007, Jon Barnett wrote:
On 4/26/07, Ian Hickson [EMAIL PROTECTED] wrote:
On Sun, 26 Jun 2005, Karl Pongratz wrote:
I had a short look at the webforms and web applications
specification at whatwg.org, I didn't find anything about modal and
modeless windows. If there is anything to improve for html, xhtml,
xforms and compound documents, then, in my opinion, the first
missing feature that comes into my mind is the lack of modal and
modeless windows.
I've now added window.open(), irrelevant=, and target= to the
specification, which should provide various ways of obtaining the
effect you're looking for. For example, with irrelevant= you can
hide the content you want to disable, and force the modal aspect of
the application to be responded to before reshowing the other parts.
Can I ask how that would work with a dialog? Would it be like this?
myframeddocument.designMode = on;
mytoolbar.hyperlinkButton.onclick = function() {
myframeddocument.body.irrelevant = true;
var dialog = window.open(hyperlinkDialog.html);
// a dialog where the user may either enter a URL or choose from a preset
list of pages on his site
dialog.onunload = function() {
processHyperlinkSelections();
myframeddocument.body.irrelevant = false;
}
}
Is that really the best way?
No, I meant everything within the one document, with sections for each
part of the app, and all but the current section having irrelevant=
set.
Would that keep dialog on top of the main browser window until it's
dismissed?
You should only use one browser window ever, as a Web app author.
I used the WYSIWYG example because I think it's a good case where
authors really want some sort of modal dialog that's synchronous in the
opener document's javascript. Is there a better way to handle that?
I'm also curious why the features argument of window.open is supposed
to have no effect. That's something I can search the archives for on
my own if it's been asked and answered.
Because none of the features that browsers support are things that
actually should be supported, as they are not things that help the user.
On Fri, 27 Apr 2007, Thomas Broyer wrote:
If I correctly understood Ian's proposal, the best way would be to not
use another window.
1. put the content of hyperlinkDialog.html within the current page
(or eventually load it within an iframe) and make it irrelevant=true
(let's call this the hyperlink editing section)
2. when you click the hyperlink toolbar button, make the hyperlink
editing section irrelevant=false
3. when the OK or Cancel button inside the hyperlink editing section
is clicked, do what's needed and switch the section back to
irrelevant=true
Pretty much.
On Sun, 27 Jan 2008, Karl Pongratz wrote:
You say:
Notwithstanding the features that make this possible, I have to say that in
general Web applications on the Web should not be written as if they are
desktop applications.
1.) We actually miss web application models. Do you know of any where
they are defined, though some which don't have any quirks? Application
models where the web browser back/next and reload button doesn't harm
anything? Maybe its time to fix this issues by defining web application
models (single page web applications and multi-page web applications)
which do not suck. It would be great if someone could point me to this
information, I would i.e. be interested of how they deal with the
problem with un-saved data if the user closes the web browser.
I don't know off hand of good resources on the matter, but this would be
an interesting area to document.
2.) Modal Windows / Modal Elements
What we actually need are modal elements inside a page. Even applications with
minor editing features such as the Google Reader uses modal windows, in this
particular case a prompt().
I would guess modal elements will be supported sooner or later. They will
replace the current alert() and prompt() function.
Maybe modal elements (or modal forms) are already part of HTML5?
Well, we have disabled= and irrelevant=, what else were you thinking
of?
On Fri, 1 Jul 2005, Sanghyeon Seo wrote:
http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/showmodaldialog.asp
On Sun, 3 Sep 2006, Anders Rundgren wrote:
[...] it is very hard to create certain types of applications without
having modal dialogs. AFAIK the existing alert() box is already modal
(at least in MSIE) so modality is well established.
On Tue, 18 Mar 2008, Travis Leithead wrote:
...but why [did WebKit implement the showModalDialog()] API and not
showModelessDialog too? I'd be interested to know the rationale for this
decision on WebKit's part.
Also, was openDialog considered (from FF)?
On Tue, 18 Mar 2008, Boris Zbarsky wrote:
My guess (not being a Safari implementor) is that there isn't much call
for showModelessDialog because you can get pretty close
Mouse wheel feedback
that the same unit name is usable with both X and Y axis. I'm not
sure if char unit should be included, though - it can be nicely emulated
with px.
On Tue, 21 Jun 2005, Matthew Raymond wrote:
Dave Hyatt wrote:
Safari in the latest Tiger update supports WinIE's mouse wheel system.
Mozilla uses addEventListener[1], which is in DOM 2 and DOM 3. (DOM 3 even
adds addEventListenerNS for different namespaces.) By contrast, IE uses
attachEvent, which is proprietary and doesn't allow you to specify the the
initial capture. As a result, I would NOT support using attachEvent in any
WHATWG standard, especially since it does not appear functionally different
from addEventListener. (Is there even an IE-proprietary event listener method
that supports namespaces?)
We also have a wheelDeltaX and wheelDeltaY so that
horizontal wheeling can be supported.
I'm thinking we should define new properties wheelDeltaX and wheelDeltaY
for MouseEvent. [2]
Chris Griego wrote:
That's incorrect. Both IE (since 5.5?) and Mozilla supports this.
Unfortunately they do it in different ways.
IE:
element.attachEvent(onmousewheel, function () {
document.title = window.event.wheelDelta;
});
Mozilla:
element.addEventListener(DOMMouseScroll, function (e) {
document.title = e.detail;
}, true);
Note that for attachEvent, you name the HTML attribute name and not the
actual DOM event type. Therefore, in DOM, if you wanted a listener for a
mousemove, you'd use the string mousemove and not onmousemove. DOM also
employs the method of using DOM at the beginning of strings that don't
correspond to the associated on attributes in HTML 4.01. Since there is no
official HTML5, this makes Mozilla's implementation above the most standards
correct.
I think I'd prefer something like mousewheel or DOMmousewheel. I'm not
sure a new |onmousewheel| attribute is called for, though, because there might
be semantic arguments against it. Anyone have a take on this, by the way?
So, I guess I'd like to see this happen:
| element.addEventListener(mousewheel,
| function (e) { document.title = getWheelDelta(e); },
| true);
|
| function getWheelDelta(e) {
| return e.wheelDeltaY;
| }
I had planned to propose this at some point but hadn't gotten
around to it yet.
I'm hoping you aren't referring to the blatantly nonstandard IE event model
shown in Chris Griego's IE example...
[1]
http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-EventTarget-addEventListener
[2] http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-MouseEvent
On Tue, 21 Jun 2005, Erik Arvidsson wrote:
Mikko Rantalainen wrote:
I assume that in the future, mouse wheels will not have huge discrete steps
anymore. So moving towards px is required. However, the page setting
will be preferred by some and it cannot be cleanly emulated with a single
px value so we need an unit in addition. Also, I selected word char
instead of row so that the same unit name is usable with both X and Y
axis. I'm not sure if char unit should be included, though - it can be
nicely emulated with px.
It seems em describes row better? However, it might be a bit weird due to
changes in font size depending on where you are in the document. (But I guess
that is already an issue with scrolling Y rows.)
If a unit is added it should probably support the other CSS units as well...
On Tue, 21 Jun 2005, David Hyatt wrote:
We actually have not implemented wheelX and wheelY yet... we just did
wheelDelta. So the other two are open for specifying. :)
On Mon, 25 Jul 2005, Chris Griego wrote:
Just to update this thread, Microsoft's new Virtual Earth uses the
mouse wheel for zooming.
http://virtualearth.msn.com/
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Mouse wheel feedback
On Thu, 17 Apr 2008, Doug Schepers wrote: Ian, thanks for compiling these messages and sending them on; are these all the emails on the topic, or do these merely represent a sampling of the mousewheel comments? They're all the mousewheel comments I could find that were waiting in my WHATWG ui-events folder. I strongly encourage the commentors to post questions directly to the WebAPI mailing list [EMAIL PROTECTED] in order that we can hear and react quickly to your comments, and make sure they are addressed in the relevant specification. When they are aggregated in this way, it is actually much harder to deal with all the issues in a fair manner, because replies on specific threads can clip out and drown out other issues, which can get lost in the shuffle. Yeah, sorry about that -- the mails mostly date from long before the WebAPI group existed. (Note that your e-mail didn't cc the original commentors, so they may not have seen the replies.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [selectors-api] Handling :link and :visited Pseudo Classes
On Wed, 16 Apr 2008, Jonas Sicking wrote: Boris Zbarsky wrote: I think that you should just require that if the UA implements :link and :visited at all any link must match one or the other. Which one is up to the UA. That allows UAs to impose security policies as needed while still allowing authors to match all links with :link, :visited. This sounds like an excellent idea to me. I agree that the above proposal is the most sensible one so far. It allows any solution to the privacy issue without compromising on the core invariant of the two pseudo-classes and without sacrificing any potential use cases. It even handles the case of a UA wanting to make site-local links follow the pseudos but site-global links not leak information. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [selectors-api] Handling :link and :visited Pseudo Classes
On Wed, 16 Apr 2008, L. David Baron wrote: On Wednesday 2008-04-16 23:26 +0200, Arve Bersvendsen wrote: Also note that it is impossible to protect against Anne's suggested exploit where you load a randomized and unique tracker image as background or content for visited links, and do the data collection serverside instead. It's not impossible; it just requires deviations from current standards and probably a lot of work. Actually that one's trivial -- just load all background images optimistically. On Wednesday 2008-04-16 14:39 -0700, Maciej Stachowiak wrote: I'd like us to understand how it is feasible to every fully solve this problem before catering to partial solutions in the Selectors API spec. My current thinking (from https://bugzilla.mozilla.org/show_bug.cgi?id=14#c65 ) is that what we'd need to do to fix this is: 1. change CSS selector matching so that :visited rules are used *only* for the non-alpha components of the 'color' and 'background-color' properties (and everything else is computed based on the :link rules) 2. make getComputedStyle and any other APIs lie about those two properties I think anything short of (1), with perhaps a few additional allowed properties, is subject to timing exploits (which are sometimes inherently engine-dependent), such as the example in https://bugzilla.mozilla.org/show_bug.cgi?id=14#attach_135350 which works at least in some older versions of Mozilla and Opera. I'm not sure whether this is something we actually *want* to do. Opera at one point had something that basically consistent of doing the layout twice, once for the user and once for DOM calls (offsetTop, etc). However, even in this solution I was able to demonstrate information leakage by using a timing attack based on how long selectors took to be processed in the two cases. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
getElementsBySelectoron all NodeLists
On Fri, 23 Sep 2005, Sjoerd Visscher wrote:
Erik Arvidsson wrote:
I'm writing this to suggest a related method that takes an element and
returns true if it matches a CSS rule
interface GetElementsBySelector {
NodeList getElementsBySelector(in DOMString cssSelector);
// returns true if an element matches the given CSS selector
boolean matchesSelector(in Element el, in DOMString cssSelector);
}
I'm not too sure about the name of this method so suggestions for a better
name are welcome (as well as any other comment of course).
Another thing that just I'm not too sure about is whether these should
include pseudo classes? It would be good but it makes things harder to
implement.
In the light of the bindings and behaviors scenario it would also be very
useful to have observers so one call tell when the matching changes. It
might be outside the scope of web apps 1.0 though?
These features would be nice for all methods that return NodeLists. As
NodeLists are live, adding a contains method, and a modification event
to the NodeList interface should cover all you need and much more.
Forwarding this feedback to public-webapi@w3.org, where this is now being
developed.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[Bindings] interfaces flattening
There are two use cases for interface flattening that I think it would be
useful for the Web IDL spec to address.
Some interfaces are huge and are defined in various places, but should
look, to authors, as if they were one coherent interface. For example, the
Window object has bits added to it by all kinds of specs. HTML5 alone
defines at least two interfaces that should really all just be Window.
It would be nice if there was a way of saying, when defining an interface,
that really that interface should be merged into a more real one. For
example:
interface Window {
// the real Window is defined here
// ...
};
// In another spec:
[Supplement] interface Window {
// the members defined here act as if they were
// defined on the real Window object
};
There are also some interfaces, like Command in HTML5, and possibly like
the URI decomposition attributes in HTML5, that aren't really interfaces,
they're just defined in one place for convenience but really should be
copy-and-pasted into a bunch of different (and practically unrelated)
interfaces. Here again, the spec arrangement is intended to be convenient
for readers of the spec, but needs to not affect the actual platform.
It would thus be nice if there was a way of saying, when defining an
interface, that really another interface needs to be imported in. For
example:
[NoInterfaceObject] interface Utilities {
// various members defined here
// these will be exposed on various objects
// independent of each other
}
[Import=Utilities] interface Tools {
// this interface should act as if the members
// of Utilities were just pasted in here
// (with any members that are also implemented
// by Tools shadowing those in Utilities)
}
There are two related cases. One is objects that implement multiple
interfaces that are available using binding-specific casting methods,
as, for instance, EventTarget. Another is inheritance, e.g. the way
HTMLAnchorElement inherits from HTMLElement. The latter is supported in
IDL. The former currently doesn't really easily fit into JS, it would be
nice if it could be made somehow more consistent (e.g. so that you could
override the EventTarget methods and affect all objects that implement
EventTarget at once).
Cheers,
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]
On Thu, 3 Apr 2008, Close, Tyler J. wrote: Maciej Stachowiak wrote: Can you please post these examples again, or pointers to where you posted them? I believe they have not been previously seen on the Web API list. I've written several messages to the appformats mailing list. I suggest reading all of them. The most detailed description of the attacks are in the message at: http://www.w3.org/mid/[EMAIL PROTECTED] with a correction at: http://www.w3.org/mid/[EMAIL PROTECTED] As noted here: http://lists.w3.org/Archives/Public/public-appformats/2008Feb/0138.html ...these are not problems with the Access Control and XXX specs. XDR is just as susceptible to these problems. The above e-mail also describes ways to mitigate these problems. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: several messages about binding stuff
to implement interfaces in ES just because there are constants defined on the interface, necessarily. It does mean though that you wouldn’t be able to refer to the constant of a native object implementing B, but you would of a host object implementing B. I don’t know if I like this discrepancy. I would just say that JS-implementable interfaces can't have constants. If someone comes up with a usecase for it, we can revisit it. In fact, are there any JS-implementable objects that do more than one operation? Be conservative. We can always expand. It's much harder to shrink. Then again, it's actually a good reason for not making any interface implementable by Object in JS too... can we have another attribute to stop that too? :-) What about other languages? I don't really mind what you do for the other languages. :-) I like to keep those sort of options open, rather than preventing them. If you prevent them now, you can add them later. If you add them now, you can't prevent them later. That's why I prefer starting with them prevented. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]
On Wed, 26 Mar 2008, Sunava Dutta wrote: IE would like to propose XDR as a new (Rec-track) spec for the Web API WG. We think there is a place for both implementations within the charter of the Web API. I think it would be very bad for the Web platform for there to be multiple ways to achieve this. We need to keep the platform simple, making it more complicated like this for no extra benefit merely acts as a divide and conquer strategy for proprietary platforms. - XDR is provably secure and does not introduce new surface area of attack compared to HTML Forms. This is blatently untrue, a number of serious security problems with XDR have already been raised (such as the fact that it encourages content-type sniffing, and the fact that it encourages people to pass their credentials to untrusted third parties). - It's really simple to program against. IMHO keeping the existing XHR API is far simpler than introducing a slightly different API that solves nearly the same problem. - It accommodates several scenarios around public data aggregation. It fails to address the majority of use cases for cross-domain data transfer on the Web. - There may be a place for an access control model today, especially around RESTful services. The model is extensible and powerful however for the draft itself it will need more design thought to build a secure implementation. I disagree, I think XHR and Access Control have been shown to be just as secure as XDR, possibly more so since they don't require bad security practices like XDR does. I strongly object to the Web API working group adopting a proprietary solution developed by one vendor with no external consultation, when the group has already spent several man-years' worth of time on a technologically superior, safer, and more comprehensive solution that has as much implementation experience and significantly more authoring experience, based on extending existing APIs instead of arbitarily introducing new, incompatible APIs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: What is Microsoft's intent with XDR vis-à-vis W3C? [Was: Re: IE Team's Proposal for Cross Site Requests]
On Mar 26, 2008, at 14:36, Travis Leithead [EMAIL PROTECTED] wrote: I strongly object to the Web API working group adopting a proprietary solution developed by one vendor with no external consultation, when the group has already spent several man-years' worth of time on a technologically superior, safer, and more comprehensive solution that has as much implementation experience and significantly more authoring experience, based on extending existing APIs instead of arbitarily introducing new, incompatible APIs. I don't see how introducing a new object is 'incompatible'. It seems to have the same degree of 'compatibility' as introducing new APIs on the XHR object. The XHR2 proposal isn't a new API. It's the same API for same-domain as cross-domain requests. -- Ian Hickson
Re: [Bindings] What does typeof return for interface objects?
On Wed, 19 Mar 2008, Cameron McCormack wrote: So really the only options are: * don’t say anything about [[Call]], and thus allow typeof to return 'object' or 'function', I don't believe that's a real option. * mandate that [[Call]] is not implemented, and thus require typeof to return 'object', or * mandate that [[Call]] is implemented (and then say what calling the function should do), thus requiring typeof to return 'function'. Those are two possible options. There's also a third option: allow interfaces to define [[Call]] the same way you allow them to define [[Construct]], thus making this vary on a per-interface basis. Requiring that [[Call]] be implemented but not saying what its actual behaviour should be is a bit strange, I think. I agree that that is not an option either. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Bindings] What does typeof return for interface objects?
On Wed, 19 Mar 2008, Cameron McCormack wrote: Do you think the spec should explicitly say that [[Call]] must not be implemented? IMO there isn’t much gain from doing that. Having a predictable result from typeof would be a useful gain, if only to stop pages depending on the arbitrary behaviour of their author's favourite browser, and thus failing on browsers that arbitrarily picked a different behaviour. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [selectors-api] Why no querySelector(All) on DocumentFragments?
On Fri, 14 Mar 2008, Maciej Stachowiak wrote: On Mar 14, 2008, at 1:56 PM, Jonas Sicking wrote: I think ability to do element-rooted selector queries (either through a new method or a :scope pseudo-element) is more important, since it's needed to replicate the feature set of JS query libraries. If we could get a :scope pseudo-element that would be an excellent solution IMHO, and would be great with scoped stylesheets as has been pointed out elsewhere in the last few days. Is that something that should be defined by this WG? It would suck to have to wait for Level 4 Selectors. Other WGs have defined selectors, but I'm not sure how good of an idea that is. I would prefer to see it in the Selectors spec, but it would have to come out of CR for that. Perhaps the editor of the Selectors spec (Hixie) would like to weigh in. Alternately, we could temporarily define the pseudo-element in the Selectors API spec. (It would be a pseudo-class, not a pseudo-element.) The :matches() proposal uses # for the concept of context node. XBL2 uses :bound-element for a similar concept. I don't think this feature is critical to the selectors API. I would recommend going ahead with the API as it is now, and moving this extension to a second version, or possibly to the next version of the Selectors spec. I think it would be a good idea for someone to start working on the next Selectors spec anyway, to spec out :matches(), the DOM attributes stuff ([#textContent*='...'], [#col=4], [#row2], etc), this, and the various other new ideas that have been suggested since Selectors last had new features suggested. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [selectors-api] Why no querySelector(All) on DocumentFragments?
On Wed, 12 Mar 2008, Boris Zbarsky wrote: javascript:var n = document.createElement(div);n.appendChild(document.createElement(span));alert(n.querySelector(:root span)); Webkit nightly returns null. IE throws (no :root support). Gecko prototype implementation returns the span, since :root will match any node with no ancestors. Webkit is correct. The Selectors spec defines :root as: The :root pseudo-class represents an element that is the root of the document. ...and here, the span is not the root of the document, it's just an unconnected element owned by the document. Thus it is possible for an element to match neither * * nor :root. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [selectors-api] Why no querySelector(All) on DocumentFragments?
On Thu, 13 Mar 2008, Boris Zbarsky wrote: Ian Hickson wrote: Webkit is correct. The Selectors spec defines :root as: The :root pseudo-class represents an element that is the root of the document. OK. It wasn't obvious to me whether that was because people hadn't considered matching against disconnected subtrees or whether they'd considered it and rejected it. I should note that it's not obvious what document the document is here, by the way... Yeah, it really should say a document. I'm not sure who's editing that document any more these days. None of which much affects my initial question about DocumentFragment. Yeah, I was just jumping in to clarify the :root thing. Personally I think you're right, it would be useful to have the method on DocumentFragment, but that's up to Lachlan. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: ElementTraversal comments
On Tue, 26 Feb 2008, Doug Schepers wrote: * I don't understand A User Agent may implement similar interfaces in other specifications, but such implementation is not required for conformance to this specification, if the User Agent is designed for a minimal code footprint. I suggest dropping this sentence. That's an odd request. A better suggestion might be to clarify the sentence, since I wouldn't have put it in if I didn't think the point needed to be made. Most of the functionality of this spec is an optimized subset of DOM2 Traversal Range, and it is intended that a UA could implement both by aliasing; however, this isn't required for conformance to this specification. I hope that clarifies it for you. It's not a subset at all. Clarification is ok too, but I think the sentence is a distraction. It can be implemented as a subset of functionality. If others agree with you, I will rework of remove the sentence in question, though. For what it's worth I didn't understand the sentence either, before you explained it. Even now, it sort of reads as saying that if you're not a minimal code footprint UA (who isn'?), you are not allowed to implement other similar specs. Or possibly, you are required to implement them, it's not clear. It certainly seems like confusing use of RFC2119 terminology. Ok, I'll consider something like that. Incidentally, from one fellow spec writer to another, in particular one who has to deal with an ungodly amount of feedback :-), I would recommend replying to each e-mail _after_ having made all the changes that you plan to do in reply to the e-mail, rather than before -- that way, you have a clear way of telling how much feedback you have left, and the commentors have a clear way of knowing when to look at the spec to see if they are happy with the new text. Just a suggestion, take it or leave it as you wish, I just find it helps. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Requirements... Re: Progress events progress...
fire. I am not sure about this. Well, I need one of those anyway, whether it's in HTML5 or elsewhere isn't a big deal. It would certainly go a long way towards ensuring that the specs that use progress events are compatible, though. I don't know if it makes sense to have authoring conformance requirements for this spec at all. I believe it does. Which is why they are in the spec. Fair enough. In that case, though, the requirements really need to be dramatically clarified. Right now the spec mixes imperative text and normative requirements, as well as being very unclear about what requirements lie on specs vs implementations and authors. Do you want a formal issue raised? How do you mean? Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Progress events progress...
On Fri, 22 Feb 2008, Charles McCathieNevile wrote: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html?rev=1.20 is a new Editor's draft, which should be ready to publish as a Working Draft, and hopefully not generate any comments so we can take it to last call about a month after that :) I'm all in favour of publishing. I don't understand the conformance in this spec. When a spec has two classess -- UAs and authors -- it's usually easy to tell which requirement applies to which. But when you add specs to the mix, I don't know how to tell which requirement applies to what. In particular, this, combined with the apparent lack of requirements on some things but presence of requirements on others, leads me to have great difficulty interpreting the actual requirements in the spec. For example: | Must be dispatched first Must be dispatched first in terms of what? By whom? I don't understand how to test this. | By default these events do not bubble, and are not be cancelable. How so? By default to what? Surely there is no default, the events bubble and are cancellable exclusively as set in their initProgressEvent() call. | Two kinds of initialisation methods are provided: one in which the | namespace is required (and must be null) Surely this is conflating the event types you are defining with the event interface you are defining. What is that requirement on? How do you test it? Does it only apply when init'ing one of the defined events? If so, it's redundant -- if the event was init'ed with a different namespace, it wouldn't be one of the defined events, and thus the requirement wouldn't apply. | Specifies the expected total number of bytes of the content transferred | in the operation. Where the size of the transfer is for some reason | unknown, the value of this attribute must be zero. The first sentence here has no requirement, it just defines the attribute's meaning. The second sentence, though, defines a requirement. Who is the requirement on? Why is the requirement to have a zero value a must when there is no requirement that the attribute have any other value? What if someone wants to use this interface with different conventions, such as making an unknown total Number.MAX_VALUE? | This parameter overrides the intrinsic bubbling behavior of the event | and determines whether the event created will bubble This definition seems to imply that the earlier comment regarding defaults has some sort of normative value, but I don't understand what -- is it saying that a ProgressEvent object, when created, has default values for its 'bubbles' attribute? Shouldn't this be left consistent with DOM Events? I don't know of any other event class that does this. Incidentally, I _really_ don't understand the definition of the User Agent conformance class: | A conforming user agent implements all the requirements described for | user agents throughout this specification. A conforming user agent | should implement all the recommendations for user agents as well. First, why is there a conformance requirement in the definition of the conformance class to which it applies? Second, aren't those two sentences contradictory? Similarly, the section starts with a paragraph saying: | A conformant implementation of this specification meets all relevant | requirements identified by the use of these terms. ...but then says about the implementations in the spec conformance class: | A conformant specification is one which includes all the requirements | identified in the section Referring to progress events from other | specifications. ...which seems to contrdict it. I don't understand what is intended. Frankly, as the editor of a spec that tries to use this spec, I'm not sure what would be best. I'm thinking that one option would be to change the focus of the Progress Events spec to be more of a guide, with the normative parts being only the definition of the IDL, with its methods defined in line with the DOM Events spec and the DOM Bindings spec, and with everything else just left up to the specs using it. The spec would then give a guide as to what event names are expected , in what order, but without making this normative. (I've already had to deviate from what this spec requires, mostly due to having more events to fire.) To make this slightly more useful, maybe some macros could be defined, similar to the fire a simple event macro I have in HTML5, but like fire a progress event which takes arguments like the event name, the progress, the total, and the target element, with the macro setting up the bubbling and canceling behaviour, etc, and returning whether or not the event's default action should fire. I don't know if it makes sense to have authoring conformance requirements for this spec at all. Anyway. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A
Re: [selectors-api]
On Tue, 19 Feb 2008, Anne van Kesteren wrote: My suggestion was to allow the implementation to throw as soon as it detects any sort of misbehavior from the NSResolver. Anne didn't like it. Given that the implementation isn't allowed to do this, what _is_ it allowed to do to comply with the deal with broken or malicious NSResolvers text? I think it has to go like this: 1. Get default namespace / resolve namespace prefixes 2. Run the group of selectors over the current DOM And I like to believe that this is what the specification requires. But maybe we should make it explicit in the method section that step 1 has to happen first and that user agents are not allowed to do both at the same time. So even prefixes that are never going to match in the current document have to be checked? e.g. if the document has no child element that has no siblings, and the author does this: :not(a1|*):not(a2|*):not(a3|*):not(a4|*):not(a5|*) :only-child, ...do we have to call NSResolver for a1..a5, even though we know no element will ever mach that selector, just in case the resolver mutates the document at some point to make it that an element matches it? That seems like optimising for the wrong case in a pretty big way. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [selectors-api] What DOM feature Selectors API belongs to?
On Thu, 14 Feb 2008, Sergey Ilinsky wrote: And as for Safari. Yes, it does have document.querySelector, but! because of some reason it doesn't have DocumentSelector/ElementSelector objects exposed, it doesn't return StaticNodeList from document.querySelectorAll, so, the question is - does it now support Selectors API? Your answer is yes. mine, according to your specification - no. Yet if the spec had had a hasFeature check, it would be returning true right now, since they would have implemented that too. So hasFeature() doesn't solve your problem either. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
RE: [selectors-api] What DOM feature Selectors API belongs to?
On Thu, 14 Feb 2008, Kartikaya Gupta wrote: Is it just me, or does seem very wrong? That means I can claim every piece of software in the world is buggy, because none of them implement a spec I just made up. They're buggy implementations of your spec, yes, if they do something that contradicts your spec. Of course, it's quite possible nobody cares about your spec. :-) I would consider a bug to be something doesn't match the spec IF it's *supposed* to match the spec. If it doesn't claim to match the spec, then you're right, that doesn't change the spec. It does, however, change what should be considered bugs in the software and what shouldn't (i.e. it's a feature, not a bug). I think it would be difficult to argue that Webkit is not attempting to implement the Selectors API. I also agree with you in that the spec shouldn't care if implementations have bugs. There may be bugs in the querySelector implementation, or there may be bugs in the hasFeature implementation, or both. Making an implementation bug-free is outside the scope of the specification. What I think *is* inside the scope is to ensure that user-agents have some unambiguous way to state whether or not they claim to implement the specification. I think the feature string is much more reliable way to do that than checking the existence of a querySelector method. Why would any browser implementor implement one and not the other? If a user-agent decides to implement a querySelector method on the Document interface that, say, provides a way to query some godlike Selector creature in a galaxy far away, then there is absolutely *no* way for an author to determine whether or not he can call querySelector and expect to return a list of nodes or the meaning of life. What about if a user agent decides to implement a hasFeature method that provides a way to query some godlike Feature creature in a galaxy far away? How can we guarentee that hasFeature() is the right hasFeature() if we can't guarentee that querySelector() is the right querySelector()? I think this is a highly theoretical concern and in practice hasFeature() is a waste of time and effort (and memory and CPU and bandwidth). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: OPTIONS and Method-Check
On Sat, 12 Jan 2008, Anne van Kesteren wrote: I have left the Method-Check header in the specification, but as the primary (and only?) use case of that header was to indicate that this is an authorization request maybe we should remove it. Opinions? I think it's useful to keep it as it gives more information to the server about what is going on and can help inform the server's response. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Window pointer
On Fri, 23 Nov 2007, Boris Zbarsky wrote: Ian Hickson wrote: Actually it does, in that navigation is the only way to change the window.document attribute's value. Removing an iframe from another document doesn't affect the iframe's Window object's document attribute. Is navigation allowed in that iframe after that? Yes; at least according to the current HTML5 draft. The spec currently splits navigation from rendering, so iframes (and browsing contexts in general) work the same mostly independent of their location. Is script allowed to run in that Window after that? According to the current spec, yes. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Window pointer
On Thu, 22 Nov 2007, Anne van Kesteren wrote: Yeah. It seems that if the Document object has changed an exception is thrown in Internet Explorer. I guess I should change the definition. Basically each XMLHttpRequest object has an associated Document object. If the Document object changes this pointer becomes null and URI resolving and origin checks will fail. If anyone has suggestions on how to phrase that that would be welcome. Document objects don't change; if we kept a reference to a Document then it would always be unambiguous. I actually think that's probably the better solution. Alternatively, we could keep a reference to both a Document and a Window and always check that the Document is the current Window.document. As for removing the Window object implying that the Document object is removed, this does not seem to be what Internet Explorer is doing per my testing: http://tc.labs.opera.com/apis/XMLHttpRequest/open/031.htm Then again, there's no specification that I know of that defines when the document attribute on the Window object changes, exactly. HTML5 does. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Window pointer
On Mon, 19 Nov 2007, Anne van Kesteren wrote: The Window is not deleted. Does that go for the document too? Yes. I'm not sure why it would be removed. After all, the Window object has references to it. Careful; a Window object can point to different Document objects during its lifetime, depending on which document is active. What should happen when the original document is no longer the active document? Directly accessing window.document at that point could be across-origin error. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Bindings] extended attribute for callback function interfaces?
On Thu, 18 Oct 2007, Cameron McCormack wrote:
Ian Hickson:
Our conclusion was that we would like a way to mark an interface as
being a callback and thus implementable as a function, with the interface
having one method, that method defing the signature of the function. Such
interfaces should, in addition, not be exposed on the global object in JS.
Why would you want an interface object not exposed on the global object
for these callback interfaces? Firefox at the moment does have an
EventListener interface object; Opera and WebKit don’t.
You wouldn't want it there because it would be useless.
For HTML 5 peculiarities, perhaps an [InhibitInterfaceObject] or
something could be a more general solution.
That would be good, yes, though then we'd need two, one for that and one
to indicate that the interface should be Function-implementable.
On Thu, 18 Oct 2007, Cameron McCormack wrote:
It doesn't make much sense for interfaces that aren't callback
interfaces.
It seems to me to make as much sense as being able to implement such
non-callback interfaces with an object with properties.
Oh no, having:
myImageData = { width: 1, height: 1, data: [0, 0, 0, 0] };
...makes much more sense than having:
myCanvasGradient = function (offset, color) { ... };
In fact, CanvasGradient is the perfect example of why we don't want
Function to be randomly implementing interfaces. Then again, it's actually
a good reason for not making any interface implementable by Object in JS
too... can we have another attribute to stop that too? :-)
Also, interfaces that are expected to get more functions added in
later versions would seem bad to make implementable as a function as
the behavior would get very confusing when the later version of the
spec is implemented.
I don’t think it would be confusing. If you had
interface A {
void f1(in Callback c);
};
interface Callback {
void f2();
};
and in script:
var a = …; // some object that implements A
var c = function() { … };
a.f1(c);
If Callback got another method later on, you’d get a TypeError saying
that ‘c’ didn’t implement Callback. So you’d need to change it
to an object with two properties.
But even if you were using the other way of implementing Callback:
var a = …; // some object that implements A
var c = { f1: function() { … } };
a.f1(c);
then if Callback got another method later on you’d still have the same
problem; ‘c’ doesn’t implement Callback. So you still need to
make a change.
...except that your code would still work. The latter shouldn't raise a
TypeError. We can't ever make the latter raise a TypeError, as that would
be breaking back-compat with legacy code, by that point.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [Bindings] extended attribute for callback function interfaces?
On Wed, 17 Oct 2007, L. David Baron wrote: There are a number of interfaces, used as callbacks, like EventListener [1], NodeFilter [2], and UserDataHandler [3], and XPathNSEventResolver [4] where an interface has a single method and is intended to be implemented by the DOM user as a callback. In ECMAScript bindings, the implementation typically accepts a raw function for such cases, in addition to (or rather than, in some implementations, perhaps?) an object with a named property for the function. Should there be an extended attribute to indicate such interfaces? (I'd note that Mozilla's IDL has such an extended attribute, [function].) Well that's freaky, we were just talking about this very thing earlier today in the #webapi channel. Our conclusion was that we would like a way to mark an interface as being a callback and thus implementable as a function, with the interface having one method, that method defing the signature of the function. Such interfaces should, in addition, not be exposed on the global object in JS. (I personally would like something even further, I'd love to just be able to put the callback signature right in the method: void callMeBack(in [Arguments=in long value, in bool active] Callback callback); ...or some such. That would get around having to actually define each of these interfaces, which is becoming a right pain in the neck for me over in the HTML5 spec. However, I don't think we need this in the Bindings spec, I can just define a preprocessor step for this for myself.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [xhr] cross site proposal headers
On Thu, 26 Jul 2007, Jonas Sicking wrote: Isn't Referer disabled by some third-party software now and then? Such as antivirus software? Another reason is probably that Referer-Root contains the exact format needed for the access check. We could use that in the access-control document probably. This seems like a loosing battle that I don't see a reason to fight. If the user (by installing software or through corporate policies) disables the Referer header, why should we try to circumvent them? That seems just likely to piss them off and then add Referer-Root to their blocking list. Referer is blocked for privacy reasons (e.g. including personal data in the URL). Referer-Root is supposed to be safe from this, by only including host/domain information. If the sites want to use the Referer header and it has been blocked the site can simply deny the request. Non-idea for the end-user, but by their own choice. Referer is also blocked when going from https:// to http://, for the same reasons as above, and we want Referer-Root available then too. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [progress-events] stalled, lengthComputable, loadstart vs begin
On Tue, 31 Jul 2007, Charles McCathieNevile wrote: * HTML 5 has an event called stalled that is dispatched after there are three seconds of no progress at all so you do not have to create your own timer scripts. 3 seconds of no progress might not be out of the ordinary depending on connection speed and distance to the host. This seems pretty arbitrary. I agree with Maciej on this one. I raised ISSUE-117 for it, but my proposal is that we do not adopt it (and that we point out to HTML-WG that 3 seconds is very arbitrary). This would be consistent with how we dealt with ISSUE-107... To clarify -- in the HTML5 spec the three seconds is indeed arbitrary, the spec just says about three seconds and it is expected that user agents will adapt that as appropriate based on the connection speed, distance to host, and so forth. Furthermore, in the HTML5 case it's specifically for streaming multimedia, where the user does care about a few seconds with no buffering going on since it can mean that the media will skip. I agree that it may well be inappropriate to have this event in the progress events metaspecification. If it's included at all, it should probably be listed as something that specifications should only include if it is considered useful for that particular case. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: DOMContentLoaded
On Mon, 9 Jul 2007, Nicolas Mendoza wrote: I ran into a problem with DOMContentLoaded today and its lack of definition. Basically exactly what elements it should wait for or not is not properly defined. It shouldn't wait for any. It just waits for the scripts to have run and the parsing to have finished and then fires. As far as I can tell the spec is exact about this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Bindings spec ready for FPWD?
On Thu, 28 Jun 2007, Cameron McCormack wrote: I’ve filled in most of the interesting stuff for the Bindings spec, so I think it could do with some more review. http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Binding4DOM/Overview.html?rev=1.38content-type=text/html;%20charset=utf-8 Wow, that's awesome. Ship it! Some comments: In 2.8.2 you have IndexPutter and NamePutter which i presume should be Setters rather than Putters. Regarding the 3.2.2 ed note, I vote for giving a mandated way; otherwise when people rely on a particular chain, it'll break in another browser and eventually all the browsers will have to do whatever IE picked (when they implement this). It would be nice if the spec could suggest some boilerplate text for other specs to include, in the way that RFC2119 does. For example: IDL sections in this specification must be interpreted and implemented as required by the Language Bindings for DOM Specifications specification. [DOMBIND] Is there anything else that a spec would have to do other than say something like the above and then use the various features you define? e.g. is there ever a case where prose is necessary to fully define something? Is it necessary to explicitly list the exceptions that a method, getter, or setter can raise? What's the purpose of the 'module' block? Is the idea that DOM Core will define an 'exception' block for DOMExceptions? For sequenceoctet it would be really nice if we could have a more native representation of a byte array than a UTF-16 string. Editorial: you have which functions, analagously to the (extraneous comma) in various places. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: ACTION-61: text for embedding part of the Window object
On Tue, 5 Jun 2007, Boris Zbarsky wrote: I've broadened the allowances in the spec. How about now? Now it effectively says UAs do whatever they want. Compatible with the real world, and existing UAs, sure. Not that useful to future UA implementors... But I'm not sure what would be. Neither am I. I'm open to better suggestions. I've changed the spec so that if you navigate a top-level browsing context whose name has been set using window.name (which is the only way to set a name on a top-level browsing context as far as I can tell) to a new origin, then the name is reset. Why only top-level? The idea is to protect the _new_ page from the previous one. In child or auxiliary browsing contexts, you don't want to have this protection, since those are exactly the cases where there will probably be another site going around and poking at your browsing context anyway. Indeed in the child browsing context case we might want to make window.name only settable by documents in the origin of the the parent browsing context's active document. In the case of auxiliary browsing contexts, you want the window to be directly accessible to the opener, at least until such time as the name changes. And this doesn't really address the concern I raised about window.name (and window targeting) seeing names set by some other site when it opened you in a popup... That wasn't what the bug was about; could you elaborate on this concern further? I'm not sure I remember which it was. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: ACTION-61: text for embedding part of the Window object
On Tue, 5 Jun 2007, Boris Zbarsky wrote: evil.com has: var win = window.open(http://victim.com;, login-popup); Now if victim.com does a window.open() into login-popup, not only does it overwrite itself (possibly unexpected), but evil.com gets a handle to the login-popup window. Generally unexpected behavior all around Getting a handle to login-popup is not a big deal. You could get that anyway by just opening the login popup window yourself anyway. The fact that the site overwrites itself is a bigger concern (usability, though, not security); but I don't see what we can do about that. It almost seems like window names should be scoped to origins But I bet that would break some site somewhere. :( Indeed, I tried doing that earlier and you complained, saying it would break sites. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Prototype chain for objects that implement multiple interfaces
On Wed, 6 Jun 2007, Boris Zbarsky wrote: To be honest, do we really think that specifying the exact prototype chain is desirable? How likely are UAs to rework the mappings between their native code and ECMAScript to follow said spec? Safari has had to implement this stuff in a Mozilla-compatible way for compatibility with Web content, as I understand it. So the sooner we define how this is to work, the sooner we can get wider consistency and less browser differences that affect authors. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
DOMContentLoaded
FYI, DOMContentLoaded is now defined as part of HTML5. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: ACTION-61: text for embedding part of the Window object
On Thu, 24 May 2007, Boris Zbarsky wrote: Ian Hickson wrote: Does: http://www.whatwg.org/specs/web-apps/current-work/#browsing ...(specifically point 4 in the algorithm) Quite frankly, I don't see how point 4 is compatible with the real world. In particular, if point 4 is applied and I create a window with window.open(), once I've done a single load in it of a page from a different site I can no longer target that window with loads. That doesn't seem to be compatible with what UAs do or what sites expect... I've broadened the allowances in the spec. How about now? If so, is the answer acceptable? I'm not sure. If the answer is accepted, that means that https://bugzilla.mozilla.org/show_bug.cgi?id=269174 is invalid. Frankly, that bothers me. In this situation, the window.name set should really not affect the name of the window for subsequently loaded pages in the same window... if they come from a different site. In fact, if I window.open a window and load some page in it, I would expect the name the opener gave that window to not affect the name the page sees for it, if the page is from a different site. That's not what UAs do at all, but what UAs do seems easily attackable to me... I've changed the spec so that if you navigate a top-level browsing context whose name has been set using window.name (which is the only way to set a name on a top-level browsing context as far as I can tell) to a new origin, then the name is reset. This doesn't affect auxiliary browsing contexts though (those with a window.opener), and in UAs at the moment those basically act like top-level browsing contexts, so this could be confusing. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Running script in non-active documents
On Thu, 6 Apr 2006, Boris Zbarsky wrote: Ian Hickson wrote: The case I was particularly concerned about was not presented vs not presented, but has its own global scripting context and is neutral to script. A document in an IFRAME has its own Window -- if you have navigated away from that document, but still have a handle to it, does it execute script elements that you insert into it? The current answer in Gecko seems to be maybe, possibly depending on what else is going on. In particular, it may depend on whether the document got placed in back/forward cache, the exact Gecko version (there are some patches that may inadvertently affect this), etc. See https://bugzilla.mozilla.org/show_bug.cgi?id=293175 for more information on part of the issue... I would say that ideally the answer here would be no. HTML5 spec now says no on this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: ACTION-61: text for embedding part of the Window object
On Tue, 7 Mar 2006, Boris Zbarsky wrote: Yet another question on window.name. What should happen in the situation that is described in https://bugzilla.mozilla.org/show_bug.cgi?id=269174 ? Does: http://www.whatwg.org/specs/web-apps/current-work/#browsing ...(specifically point 4 in the algorithm), in conjunction with * the target= attribute definition (sixth paragraph): http://www.whatwg.org/specs/web-apps/current-work/#following0 * the window.name attribute definition: http://www.whatwg.org/specs/web-apps/current-work/#name3 ...answer your question? If so, is the answer acceptable? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Method overloading in IDL
On Tue, 22 May 2007, Bjoern Hoehrmann wrote: The problem we want to solve with the ES Bindings specification is that Who is we here? IMHO, the problem we want to solve is the lack of a clear and succint yet detailed formal definition of how DOM objects in JS should be implemented. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [XMLHttpRequest] update from the editor
On Mon, 14 May 2007, Maciej Stachowiak wrote: The question we should be examining is whether [text/xsl] is actually used in practice. If it is, then the right course of action is to get it registered with the IETF (and presumably marked deprecated). If it isn't, then we can safely require it not to be treated as XML. My research (which is biased against non-HTML files) suggests that text/xsl is seen about as often as the following types: application/x-zaurus-xls application/x-php application/vnd.adobe.xfdf application/x-autocad text/xsl application/octet-stream-dummy application/x-java-archive application/text text/texmacs model/iges application/x-dvi I think the bias against text/xsl is high. The type application/xslt+xml was present in my sample about 2.8 times more than text/xsl, and application/xslfo+xml was present about 1.5 times more. The type text/x-xslt was present about 0.1 times as much as text/xsl. I expect the data to be biased against application/xslt+xml and text/x-xslt about equally. However, I expect it to be biased quite strongly in favour of application/xslfo+xml (relatively speaking). The MIME type application/xsl+xml appeared about 0.2 times as much as text/xsl, but I don't know what the bias in favour or against that type would be. However, this data is for all intents and purposes worthless. All of the types mentioned in this study were seen so rarely (in the order of 0.04% of the multibillion document sample) that the numbers are probably swamped by the error margin. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: File upload interface (fwd)
A while back I asked Jesse Ruderman to do a security review of the FileUpload API. His response is below. I apologise for the tardiness of my sending these comments (he wrote them months ago, though they still apply, as the draft has not changed). - FileDialog: open() says When called, this method MUST prompt the user with a means to select one or more files. This seems to exclude the possibility of restricting the call to times when pop-up windows are allowed. (And I think restricting it in that way would be a good idea, if only to prevent web pages from badgering you with file pickers and holding your browser hostage until you give in and select the file they want.) I'm worried about the asynchronous nature of open(). Does that mean scripts can continue running in the background, doing things like calling alert() or calling open() again? Having an asynchronous API for a dialog seems strange to me. I'm surprised that the open() method doesn't let you specify what content-type you want (e.g. images, sound files, mp3 files, etc). I'm also surprised it doesn't let you specify whether you want a single file or multiple files, always assuming you want multiple files. Requiring users to call addEventListenerNS with a long, opaque namespace string isn't very nice. The only things you can do with a file object are getDataAsString, etc. For large files it is better to be able to iterate through lines or characters in the file, and even better to be able to seek. getDataAsString does not let you specify an encoding. It also does not specify what should happen if you ask for UTF-8 and the file is invalid UTF-8 (some programs substitute question marks in diamonds, some programs warn). Why is all this stuff separate from the file upload form control? There will always be apps where you want to upload a file to a server, and many of them would love to be able to show a preview of what you're about to upload, do some quick client-side validation, etc. The Integration with XMLHttpRequest section is empty. fileName: The name of the file, exclusive of its path. Good. - Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Network API editor's draft
On Wed, 7 Mar 2007, Charles McCathieNevile wrote: Thanks to Gorm and the WHATWG, we have http://dev.w3.org/cvsweb/~checkout~/2006/webapi/network-api/network-api.html Note that the WHATWG version of this draft is in heavy flux; there are hundreds of outstanding comments on it. Is the intent that this specification replace the WHATWG version? (I am reluctant to just remove the WHATWG part of the text because development on the last specification for which I did that -- the Window spec -- has now ground to a halt and left me with significant extra work, as I now have to move the definitions back to HTML5 to deal with the more complicated cases which the Windows spec says are out of scope.) Could you give an exact list of the changes between the WHATWG draft and this one? (Ideally to the level of individual word and markup changes?) Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: New Progress Events spec
On Wed, 7 Mar 2007, Charles McCathieNevile wrote: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/progress/Progress.html Early comments: XmlHttpRequest should be XMLHttpRequest. I disagree with in general specifications should not specify that progress events must occur. I don't think requiring these events causes any backwards incompatibilities. The incompatibility is if someone in new content assumes those events take place, but that will happen whether or not a requirement uses a SHOULD requirement. In fact the entire Considerations for Backward Compatibility section doesn't really make any sense to me. I think the event 'progressStart' should be called 'start'. I think the event 'progressError' should be 'error' for backwards compatibility. I think the event 'progressCanceled' should be 'abort' for backwards compatibility. I think the event 'progressComplete' should be 'load' for backwards compatibility'. The spec doesn't say how to decide whether to fire 'error' or 'abort'. The spec implies that 'error' and 'abort' are not mutually exclusive with 'load'. The spec says that the events must be cancelable but does not define their default action. The initialisation methods for ProgressEvent are missing a lengthComputableArg argument in the IDL. The following requirement both abuses RFC2119 terminology and makes no sense from a conformance point of view: This method may only be called before the progress event has been dispatched via the dispatchEvent method, though it may be called multiple times during that phase if necessary. The specification is lacking requirements on user agents to set the event attributes appropriately. I would recommend changing the start of the The ProgressEvent events section to more clearly indicate exactly what it is other specifications are to do. As it stands I don't know that I'd be able to appropriately use this specification to write another one that uses these events in a fully well-defined and unambiguous way. Please have Bjoern review this specification for consistency with DOM3 Events. The acknowledgements refer to the WHATWG progress event proposal as being invaluable in preparing this draft, but that seems unlikely since there is no such proposal (the provided reference is to the progress element, a UI widget). HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: ISSUE-112: Should progress run a UI or rely on other stuff too?
On Sat, 10 Feb 2007, Charles McCathieNevile wrote: Are there any other actual use cases? What else would you use the progress events for if not a standard progress UI? Measuring how your network operations are going, whether to time them out andswap to something else, ... Could you elaborate on this? It seems like this use case would need much stricter restrictions on frequency and timing of events. I didn't realise this was one of the requirements for this spec (and I definitely didn't realise it was the only requirement -- I'd assumed the intent was to do what Maciej described, but the existence of this issue clearly indicates that those use cases were not part of the initial requirements and research for this feature). The issue here though is actually whether you should be able to build your entire UI on nothing but progress events, or whether you should rely on other specifications for things like the start and end, and get them to define that progress events can be fired. I think it's clear that interoperability will be best served by having the events for each load feature described in conjunction with that load feature's processing model. It is extremely difficult to write unambiguous and implementable abstract specifications. (Not to say it's impossible, but it is certainly not something I would recommend.) In that scenario, if you build a UI element you would make a standard UI widget that assumed no progress events, and a progress event extension that, if it got them, would refine the UI widget by adding some sense of progress. For example, a rectangular bar might normally have a cylon eye effect, but if you get progress events that tell you how far along you are you could change that to have a proportional progress bar. Maciej's model seems amenable to this too. I don't think Maciej is arguing that the existing events (namely, 'load', 'error', and 'abort') should be dropped, or made redundant; I would expect his proposed processing model to augment them. As Maciej points out, that means you have to write widgets for each type of operation that might fire progress events. On the other hand it means you aren't relying on progress events in order to have at least some UI. I don't understand why we can't leverage the existing event structure while still providing for Maciej's use cases, and get easily authored backwards compatibility at the same time. And it lightens the requirements on the progress event spec. Ease of spec writing should not be a concern here. There's an order of magnitude more implementors than spec writers, many orders of magnitude more authors than implementors, and yet more orders of magnitude more users than authors. Thus the needs of the users trump the needs of the authors, which trump the needs of the implementors, which trump the needs of the spec writers. We (the spec writers) are the slaves at the bottom of the chain -- on us falls all the hard work. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: ISSUE-112: Should progress run a UI or rely on other stuff too?
On Sat, 10 Feb 2007, Web APIs Issue Tracker wrote: Is it worth adding to progress events to support this use case, or should it stay as small as possible? Are there any other actual use cases? What else would you use the progress events for if not a standard progress UI? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Progress event spec
On Sat, 27 Jan 2007, Ian Hickson wrote: I haven't actually looked at the spec, but, I would recommend something along the lines of: Apparently I should have given rationales, so: MUST fire at zero bytes ...so that progress bars can be initialized with the right length, or indeterminate length if there is no right length. MUST fire again at the end, even if that is zero bytes ...so that progress bars can be easily guarenteed to reach the 100% mark, which is important for usability. SHOULD fire at least once every 500ms in between the above two events, unless no progress has been made in that time. ...so that smooth UI can be guarenteed. SHOULD NOT fire more than once every 10ms. ...so that poorly written code doesn't result in fatal performance hits. It's important, in terms of API design, to make the main use cases trivial. I believe the above design would do that. In the common case, I would expect a 'progress' event to simply update the max and value attributes of the HTML5 progress element; with the above characteristics, such an event handler becomes a trivial two-line handler with no complications, and you would not need any other handlers to do anything special (e.g. no need to track the 'load' event to end the progress bar). (Further to that, if the 'progress' event does indeed go ahead with setting 'max' to 0 when it is unknown, I'll update the HTML5 spec to make max=0 cause an indeterminate progress bar, thus making it even simpler.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Progress event spec
On Sat, 27 Jan 2007, Jim Ley wrote: Ian Hickson [EMAIL PROTECTED] MUST fire again at the end, even if that is zero bytes ...so that progress bars can be easily guarenteed to reach the 100% mark, which is important for usability. Using onload is sensible for that, there is no point to require an extra event which breaks backwards compatibility. Could you elaborate on this backwards compatibility problem? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Progress event spec
On Sun, 28 Jan 2007, Jim Ley wrote: Could you elaborate on this backwards compatibility problem? Sure, if authors go .post() - update UI to indicate something's started happening event.onprogress - indicate progress event.onprogress (complete) - update UI to indicate things have finished Then user agents which do not get progress events never see the complete status reflected in the UI, however if the UI uses onload to indicate things have finished then the script is compatible with images and XHR in user agents today. Oh I'm not suggesting we get rid of the 'load' event. If authors chose to only target newer UAs that's an authoring problem, not a backwards compatibility problem. But then authors can always make that kind of mistake with new features. All I'm saying is that we should make the progress events useful enough that you can make the entire progress UI updating with them (setting max and value each time), instead of having to have three sets of code (one to set the max, one to set the value, and one to set the 100% value). So long as we have good examples, showing the progress UI be enabled before the events, updated by the events, then removed by the handler for the existing 'load' event, we can easily foster backwards-compatible UI that will work identically in old and new UAs with the exception of having nice updating progress bars in the new UAs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Selectors API naming
On Fri, 26 Jan 2007, Doug Schepers wrote: A way to reduce the number of typos might be to drop the trailing s from both method names. It's equally clear what it does IMHO. Hmmm... that's a reasonable point, but Selector (singular) is a bit misleading. You can provide multiple criteria. If it helps, as one of the editors of the Selectors specification, I would say that it isn't incorrect to consider div, p to be a selector (singular). The terminology in the spec says that technically that's a group of selectors, but I wouldn't worry about that. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Progress event spec
On Fri, 26 Jan 2007, Boris Zbarsky wrote: So I would hope that the spec says that not only is this implementation defined but may differ depending on the actual network connection in use I haven't actually looked at the spec, but, I would recommend something along the lines of: MUST fire at zero bytes MUST fire again at the end, even if that is zero bytes SHOULD fire at least once every 500ms in between the above two events, unless no progress has been made in that time. SHOULD NOT fire more than once every 10ms. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Selectors API naming
On Thu, 25 Jan 2007, Anne van Kesteren wrote: So the WG just discussed in a little over an hour a counter proposal to the current naming[1] and came up with: * getElementBySelectors() * getElementListBySelectors() I don't really like them. Supposedly I'm to edit the draft to reflect this... Given that this discussion was done behind closed doors, and given that there is certainly not consensus on this (the first reaction I saw on IRC to this was wow, those names suck!), I think it is very disappointing to see the working group override the editor on this. It sets a bad precedent in the new world of public Web spec development. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Selectors API naming
On Thu, 25 Jan 2007, João Eiras wrote: Given that this discussion was done behind closed doors, and given that there is certainly not consensus on this (the first reaction I saw on IRC to this was wow, those names suck!) I find these much better than all other propositions, and I'm not lazy to type longer method names, if they're descriptive. So, it's a matter of personal opinion that names suck. My argument is not that the names suck. My argument is that there is not concensus, that the decision process was opaque and behind-closed-doors, and that having the working group override the editor on such a trivial issue as naming is a bad precedent for open Web spec development. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Selectors API naming
On Thu, 25 Jan 2007, Jon Ferraiolo wrote: Editors are in charge of the words in a spec and simply make sure that the will of the WG is reflected in the spec. I don't understand where there is bad precedent in this. While this has indeed been the way that the W3C has developed specifications for a long time, the W3C's own technologies -- HTML, HTTP, etc -- have led the Web to a place where massive collaboration is the norm. The blogosphere and sites like Wikipedia are one example of this, but another is the collaborative open spec development that has for a long time been the hallmark of the IETF, but is now becoming standard in other areas, like the Microformats community. The Web API working group long ago decided to follow open principles as well. Web specifications affect everyone in the Web community, and so Web specifications should be developed in the open. The term Working Group Member is misleading -- there should not be anything special to being a W3C member when it comes to the development of Web technologies. Given the prohibitively high price of W3C membership, not to mention the cost of attending regular meetings around the globe, it is absolutely imperative that we not limit equal participation to only those capable of paying the W3C to become Working Group members. Thus, an editor's responsibility is not simply to make sure the will of the Working Group Members is reflected in the spec -- the editor's responsibility is to make sure the will of the entire Web community is reflected in the spec, and the Working Group's responsibility is to make sure that the editor indeed does this. On the other hand, it would be very bad precedent if editors attempted to override the will of the WG to make specs reflect their own personal opinions. Yes, naturally. Nobody, I hope, is suggesting that this should happen. Editors should always try to balance the opinions of all those in the wider community, and develop well-balanced, consistent APIs and technologies that handle the 80% case well, without falling prey to scope creep and certainly, as you point out, without letting their own opinions make them ignore important parts of the community. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Selectors API naming
On Thu, 25 Jan 2007, Nicolas Mendoza wrote: I suppose you agree though, that after discussing something in the open (Hey, even I was able to comment on the naming scheme. My voice was heard, without being member of any w3c group.) someone needs to take a decision. It seems natural that a working group concludes on something based on the feedback it gets, and as far as I can see the result is according to that, in this matter. I think the mailing list is fine. However, I don't see that the current decision is any closer to the community's consensus opinion than Anne's own compromise proposal, and therefore I don't understand why the working group would override the editor on this. It raises a bad precedent. If the editor is to be overriden on every little thing -- especially in cases like this, where we're moving from a set of names that a minority liked to another set of names that a different minority likes -- then we should change the editor, as it indicates that the editor is not being trusted by the working group. (I don't think we should change the editor -- I think Anne is doing a fine job. I think the working group should let him do his job without micromanaging the names.) I should probably point out that I represent a company whose opinion is that the longer names are fine. I'm not worried about what the names are. My point is that the process by which the names were obtained is not a good one, IMHO. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Editorial Control (was: Selectors API naming)
On Thu, 25 Jan 2007, Doug Schepers wrote: [...] I made exactly the point that you did -- you should have an editor who makes decisions, but can be overriden by a working group when the decisions are not representative of the community. As you say, the WG here just moved from one minority opinion to another minority opinion. So this isn't a case where Anne's decision was not representative of the wider community. As you say, this is a minor issue. Given those two points, I don't see why the WG would override the editor on this case. (And yes, I think a benign dictator (Anne) answerable to a committee (the WG) and representing the wider community will create far better specifications than a committee (the WG) answerable to a dictator (TBL) and representing the interests of only the companies involved.) Someone needed to settle the discussion, and those of us who attended the meeting did so. What makes those of us who can afford to pay the W3C membership fee and afford to attend the meetings more entitled to make this decision than the rest of the community, or than the editor? Especially in cases where there is no clear concensus either way, so that the editor is not being forced down a path that represents the community better, but is just being forced to take a different minority position? Especially on an issue that, as you point out, will never be more than a minor pain? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: heads-up on use of unnamespaced event types in XBL2
On Mon, 8 Jan 2007, Anne van Kesteren wrote: On Mon, 08 Jan 2007 15:07:05 +0100, Bjoern Hoehrmann [EMAIL PROTECTED] wrote: FYI, the XBL2 spec currently defines two events, 'xbl-bound' and 'bindings-are-ready', without namespaces. If anyone thinks that these events should be namespaced, please let me know. This is fine with me so long as 'bindings-are-ready' is renamed to 'xbl-bindings-are-ready'. Having two XBL-specific events where only one starts with 'xbl-' is rather confusing, and I don't see how the second event neither is XBL-specific nor should be XBL-specific. Yeah, I agree with that. What's the rationale for not having bindings-are-ready and bound? 'bound' on its own is too vague. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
heads-up on use of unnamespaced event types in XBL2
FYI, the XBL2 spec currently defines two events, 'xbl-bound' and 'bindings-are-ready', without namespaces. If anyone thinks that these events should be namespaced, please let me know. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: NSResolver Re: Selectors API naming (off-topic)
On Fri, 22 Dec 2006, Charles McCathieNevile wrote: ([...] I understand why [the CSSWG] have special-cased HTML, although it isn't something that strikes me as a brilliant architectural principle in general and I am wondering what the pros and cons are of going further along those lines). FWIW, the special casing was done at the request of the HTML working group. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
