[XHR2] overrideMimeType behavior
One issue raised briefly when discussing ArrayBuffer integration but not resolved was how to handle overrideMimeType(). The issue is whether calling overrideMimeType() can cause already downloaded data to be re-interpreted with a different charset. From my reading of the spec, this is the case. Calling overrideMimeType() with a specified charset sets the current override charset which overrides the final charset which is used in the text response entity body algorithm to decode the response entity body (i.e. bytes from the network) into a DOMString. However WebKit and Gecko currently do not behave in this way and while I can't speak for the rest of the WebKit community I would be reluctant to change WebKit to what the spec currently states. In both of these implementations the override mime type is checked once when the HTTP headers are received from the network in order to determine how to decode the data. From that point on, setting overrideMimeType() is a no-op. In addition, in the current WebKit implementation we do not preserve the raw bytes from the network after decoding them to UTF-16 in order to produce the .responseText DOMString. Since conversion from an arbitrary charset to UTF-16 is not always invertible, this makes the current semantics impossible to implement without keeping an extra copy of the data around. I would strongly prefer not to keep an extra copy if possible since this will only be memory bloat for an extremely rare use case. I propose that overrideMimeType() throw INVALID_STATE_ERR if called when the send() flag is true. This should still allow authors to declare a mime type and optionally a charset on requests without requiring an arbitrary re-decoding of data after it has been received. - James PS: There's a related discussion about how to handle encoding semantics and the .responseArrayBuffer property, but that's for another thread.
[widgets] RfC: LCWD of Widget Packaging and Configuration; comment deadline October 26
This is a Request for Comments for the October 5 Last Call Working Draft (LCWD) of the Widget Packaging and Configuration spec: http://www.w3.org/TR/2010/WD-widgets-20101005/ The previous publication of this spec was a Candidate Recommendation (Dec 2009) and it returned to LCWD because implementer feedback and discussions with the I18N Core WG resulted in the group deciding to replace a reference to the ITS spec with a span element and dir attribute. For more information about this change and others, see: http://www.w3.org/TR/2010/WD-widgets-20101005/#changes We asked the I18N Core WG to review this LC and feedback from others is welcome.The comment period ends October 26. -Art Barstow
Re: [progress-events] Update
On Tue, 05 Oct 2010 19:31:12 +0200, Olli Pettay olli.pet...@helsinki.fi wrote: May I ask why you think the interface member names are terrible? I should probably have left out that comment. It is just that they are inconsistent — lengthComputable vs total — and seem to imply a specific kind of process — loaded. I would have preferred hasMax, value, and max / hasTotal/totalKnown, current, and total or some such. Anyway, changing this is not worth it. -- Anne van Kesteren http://annevankesteren.nl/
RE: Seeking agenda items for WebApps' Nov 1-2 f2f meeting
I'm flexible. I will be at TPAC the entire week and will shift scheduling to attend the IndexedDB sessions. Cheers, Eliot -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps- requ...@w3.org] On Behalf Of Pablo Castro Sent: Monday, October 04, 2010 8:03 PM To: Arthur Barstow; ext Eric Uhrhane; Jonas Sicking; Jeremy Orlow; public- webapps; Arun Ranganathan Subject: RE: Seeking agenda items for WebApps' Nov 1-2 f2f meeting Are these slots more or less frozen at this point? Just wanted to confirm to make travel arrangements. Thanks -pablo -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Wednesday, September 29, 2010 5:41 AM To: ext Eric Uhrhane; Jonas Sicking; Jeremy Orlow; Pablo Castro; public- webapps; Arun Ranganathan Subject: Re: Seeking agenda items for WebApps' Nov 1-2 f2f meeting I added the following slots for November 2: [[ http://www.w3.org/2008/webapps/wiki/TPAC2010#Tuesday.2C_November _2 13:30-15:00: Indexed DB 15:30-16:30: Indexed DB 16:30-18:00: File * APIs ]] Of course we can fine-tune the times as needed. Arun - we reserved a speaker phone for remote participants for both days. -Art Barstow On 9/28/10 5:45 PM, ext Eric Uhrhane wrote: Works fine for me. I'll be there all of Monday and Tuesday. Due to jetlag morning vs. afternoon's probably irrelevant to me, as I won't have any idea what time it is ;'. On Tue, Sep 28, 2010 at 2:30 PM, Jonas Sickingjo...@sicking.cc wrote: The later the better for me. If we can make it after noon I'll be there for sure. / Jonas On Tue, Sep 28, 2010 at 1:37 PM, Jeremy Orlowjor...@google.com wrote: I'm OK with any time slot. On Tue, Sep 28, 2010 at 8:57 PM, Arthur Barstowart.bars...@nokia.com wrote: Hi All, Currently, no one has requested a specific day + time slot for any of the proposed topics: http://www.w3.org/2008/webapps/wiki/TPAC2010 When our IndexedDB participants agree on a time slot on Tuesday the 2nd, I'll add it to the agenda. Pablo, Jonas, Jeremy - please propose a time. Day + time slot proposals for the agenda topics already proposed are also welcome (as are proposals for additional topics). -Art Barstow On 9/28/10 3:28 PM, ext Pablo Castro wrote: It looks like there will be good critical mass for IndexedDB discussions, so I'll try to make it as well. Tuesday would be best for me as well for an IndexedDB meeting so I can travel on Sunday/Monday. -pablo -Original Message- From: Jonas Sicking [mailto:jo...@sicking.cc] Sent: Tuesday, September 28, 2010 10:53 AM To: Jeremy Orlow Cc: Pablo Castro; art.bars...@nokia.com; public-webapps Subject: Re: Seeking agenda items for WebApps' Nov 1-2 f2f meeting I'm not 100% sure that I'll make TPAC this year, but if I do, I likely won't make monday. So a tuesday schedule would fit me better too. / Jonas On Tue, Sep 28, 2010 at 8:36 AM, Jeremy Orlowjor...@google.com wrote: Is it possible to schedule IndexedDB for Tuesday? I'm pretty sure that I can be there then, but Monday is more up in the air at this moment. Thanks! Jeremy On Thu, Sep 2, 2010 at 3:28 AM, Jonas Sickingjo...@sicking.cc wrote: I'm hoping to be there yes. Especially if we'll get a critical mass of IndexedDB contributors. / Jonas On Wed, Sep 1, 2010 at 7:18 PM, Pablo Castropablo.cas...@microsoft.com wrote: -Original Message- From: public-webapps-requ...@w3.org [mailto:public-webapps-requ...@w3.org] On Behalf Of Arthur Barstow Sent: Tuesday, August 31, 2010 4:32 AM The WebApps WG will meet face-to-face November 1-2 as part of the W3C's 2010 TPAC meeting week [TPAC]. I created a stub agenda item page and seek input to flesh out agenda: http://www.w3.org/2008/webapps/wiki/TPAC2010 [TPAC] includes a link to the Registration page, a detailed schedule of the group meetings, and other useful information. The registration fee is 40€ per day and will increase to 120€ per day after October 22. -Art Barstow [TPAC] http://www.w3.org/2010/11/TPAC/ For folks working on IndexedDB, are you guys planning on attending the TPAC? Given the timing of the event it may be a great opportunity to get together and iron out a whole bunch of issues at once. It would be good to know ahead of time so we can all make plans if we have critical mass. Thanks -pablo
[Bug 10798] Find a new home for Selection
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10798 Ms2ger ms2...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | AssignedTo|dave.n...@w3.org|i...@hixie.ch --- Comment #6 from Ms2ger ms2...@gmail.com 2010-10-05 18:33:53 UTC --- Actually, this still needs to go from HTML, I guess. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Comment on Widget Interface...
hi Addison,
On Thu, Sep 30, 2010 at 8:57 PM, Phillips, Addison addi...@lab126.com wrote:
Are you talking about a script using navigator.language?
Not really, unless you expect navigator.language to be how widget containers
expose the runtime locale.
Widget PC describes how a widget is packaged (which can include
localization) and how it is configured (what the widget container should do
when it unpackages and runs the widget). The container determines what the
locale is going to be for the widget (which, as you pointed out in your
earlier reply, is implementation specific). This, in turn, affects what
language the 'name' or other fields returned by the Widget Interface are in.
I'm suggesting that you need to provide programmatic access to this value,
which may be distinct from navigator.language. Text direction for those
fields might also need to be exposed.
Ok, so there are essentially three problems we need to tackle here:
1. Exposing the actual language which was used (during Step 7 in PC)
to choose the localize the content for name and description (we don't
expose). We have this bit - this is solved:
[[
9.1.5. Rule for Getting a Single Attribute Value
...
E. Let lang be the language tag derived from having processed the
xml:lang attribute on either element, or in element's ancestor chain
as per [XML]. If xml:lang was not used anywhere in the ancestor chain,
then let lang be an empty string.
F. Associate lang with result.
]]
And similarly in section 9.1.8. Rule for Getting Text Content. [2]
Essentially, for each element or attribute that is displayable, we
have an abstract object (a so called 'localizable string)' that is
represented as:
{string: ' unicode | ltr marker | rtl marker | lro marker | rlo marker |',
lang: language tag | empty string}
2. Given the liberal way that PC selects languages, we could end up
with each attribute in the widget object containing different
languages:
widget.name; /*in English*/
widget.shortName; /*unlocalized*/
widget.description; /*in French*/
So, we basically need to extend DOMString:
interface LocalizedString : DOMString {
readonly attribute DOMString lang;
}
Then:
widget.name.lang === en;
3. At runtime, upon getting an attribute from the Widget object (e.g.,
widget.name), you need to display that properly. The case is:
$(#somePElement).innerHTML = widget.name; //in Arabic
To display it properly, we need something like the algorithm described in:
http://www.iamcal.com/understanding-bidirectional-text/
WDYT?
[1]
http://dev.w3.org/2006/waf/widgets/#rule-for-getting-a-single-attribute-valu0
[2] http://www.w3.org/TR/widgets/#rule-for-getting-text-content
--
Marcos Caceres
Opera Software ASA, http://www.opera.com/
http://datadriven.com.au
Re: [progress-events] Update
On Tue, 05 Oct 2010 19:36:27 +0200, Anne van Kesteren ann...@opera.com wrote: Thanks for taking this over Anne. On Tue, 05 Oct 2010 19:31:12 +0200, Olli Pettay olli.pet...@helsinki.fi wrote: May I ask why you think the interface member names are terrible? I should probably have left out that comment. It is just that they are inconsistent — lengthComputable vs total — and seem to imply a specific kind of process — loaded. I would have preferred hasMax, value, and max / hasTotal/totalKnown, current, and total or some such. Anyway, changing this is not worth it. Right. I am not overly fond of the names either. As I recall, they were copied from SVG where people were actually using this already, to reduce incompatibility. I agree that changing them is probably not worth the effort (or the bike-shedding of *exactly* what new names would be the best... I would vote for Sarah, John, Stuart, and Mary, because they're nice names and if you have a cartoon in mind of the different characters with their different functions they are as memorable as anything else. Which is to say, not actually all that much more intuitive in the grand scheme of things). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
ISSUE-136 (getCoordsAt): Consider adding MouseEvent.getCoordsAt(element)
ISSUE-136 (getCoordsAt): Consider adding MouseEvent.getCoordsAt(element)
http://www.w3.org/2008/webapps/track/issues/136
Raised by: Doug Schepers
On product:
Jonathan Watt
http://lists.w3.org/Archives/Public/www-dom/2010OctDec/0013.html:
[[
Background:
Positioning elements based off the position of a pointer event is regularly
tripping people up in SVG, and with the advent of CSS-transforms, I imagine also
in HTML.
To position an element based off the position of a pointer event you need to get
the coordinates of the event in the local coordinate system of the element. To
do that currently authors have to get the *correct* element-to-root transform,
invert it, create an SVGPoint, copy the event coordinates to the SVGPoint, then
use the inverted transform to transform the point and read back the coordinates.
For something so simple, it's not obvious that this is what you need to do, or
even how to do it.
Proposal:
To make life easier for authors I'd like to propose the addition of a
'getCoordsAt' method to the MouseEvent interface. This method would be passed
the element at which the local coordinates of the event are required, and return
an object implementing the SVGPoint interface[1] (or a new interface
implementing 'x' and 'y' properties).
I've uploaded a JavaScript implemented demo of this method here:
http://jwatt.org/svg/tmp/mouse-relative-positioning.svg
See also the comments in the source code.
]]
[[
// This is a demonstration of getCoordsAt() - a proposed addition to the DOM
// interface 'MouseEvent' - that would save authors from having to work with
// matrices when positioning elements based on the location of a pointer event.
//
// This file demonstrates getCoordsAt for SVG only, but it would be just as
// useful in HTML, especially with the advent of CSS-transforms.
// JavaScript implementation of getCoordsAt for SVG:
if (!MouseEvent.prototype.getCoordsAt) {
MouseEvent.prototype.getCoordsAt = function(element) {
var SVGNS = 'http://www.w3.org/2000/svg';
var svg = document.createElementNS(SVGNS, 'svg');
var pt = svg.createSVGPoint();
pt.x = this.clientX;
pt.y = this.clientY;
return pt.matrixTransform(element.getScreenCTM().inverse());
}
}
]]
