On Sep 28, 2012, at 12:17 PM, Rik Cabanier wrote:
>
>
> On Fri, Sep 28, 2012 at 9:31 AM, Dirk Schulze wrote:
> Hi,
>
> Would it be possible to extend CanvasRenderingContext2D with the functions:
>
> void addPath(Path path); - which adds a Path object to the current path on
> Canvas?
> attr
On Fri, Sep 28, 2012 at 9:31 AM, Dirk Schulze wrote:
> Hi,
>
> Would it be possible to extend CanvasRenderingContext2D with the functions:
>
> void addPath(Path path); - which adds a Path object to the current path on
> Canvas?
> attribute Path currentPath; - that returns a copy of the current pa
Hi there,
This email is to complete my proposal sent earlier this month.
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-September/037185.html)
Unfortunatly the URL that I provided on that email are now brokens.
The examples and the documentation have been moved from the "docs"
folder to
On Fri, 28 Sep 2012, Boris Zbarsky wrote:
> On 9/28/12 2:26 PM, Ian Hickson wrote:
> > > 5) What happens when this doesn't match the origin or effective script
> > > origin or whatever of the global object the script is evaluating
> > > against.
> >
> > I think this is specced. Can you
On 9/28/12 2:26 PM, Ian Hickson wrote:
5) What happens when this doesn't match the origin or effective script
origin or whatever of the global object the script is evaluating
against.
I think this is specced. Can you elaborate on what you mean?
As long as it's specced, great. The
On Fri, 28 Sep 2012, Boris Zbarsky wrote:
>
> If you're trying to define behavior for various cases of javascript:,
> you should consider defining the following, to the extent that they're
> not already defined:
>
> 1) Whether the script executes (compare vs ),
> but note that some UAs _d
On 9/28/12 1:30 PM, Anne van Kesteren wrote:
Well that is interesting. So the document encoding is not solely a
query component affair?
At least not for Gecko, no.
Does this only apply to javascript URLs? I
cannot get this to work for data URLs.
Looks like there's some javascript:-specific
On Fri, Sep 28, 2012 at 5:45 PM, Boris Zbarsky wrote:
> In the case I was testing (just loading a file from file://), the
> javascript: URI is created from the string 'javascript:alert("%E2%84")' with
> charset set to ISO-8859-1. When the URI parser is done with that, it has
> converted it to an
On 9/28/12 11:34 AM, Boris Zbarsky wrote:
I'm not sure why it never hits the alert. A similar testcase not inside
the live dom viewer works just fine.
Oh, I see why it's different.
In the case I was testing (just loading a file from file://), the
javascript: URI is created from the string 'j
On 9/28/12 11:19 AM, Anne van Kesteren wrote:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1809
Gives "â" in Chrome (charCodeAt -> 226). I cannot get it to alert in
my Nightly (18.0a1 (2012-09-28), Mac), Opera yields one FFFD and
Safari two. So maybe this is less of a problem th
On Fri, Sep 28, 2012 at 4:52 PM, Boris Zbarsky wrote:
> On 9/28/12 7:45 AM, Anne van Kesteren wrote:
>> What I am wondering about is why e.g. %E2%84 results in a code point
>> in both Gecko and Chrome and whether that is required for
>> compatibility (in Opera I get U+FFFD as I expected).
>
> I'm
On 9/28/12 7:45 AM, Anne van Kesteren wrote:
I have been looking into defining javascript URLs on top of
http://url.spec.whatwg.org/ and would like some help. You get the
JavaScript source by concatenating the path and fragment, with "#"
inbetween of course, and then removing the percent encoding
Hi,
I have been looking into defining javascript URLs on top of
http://url.spec.whatwg.org/ and would like some help. You get the
JavaScript source by concatenating the path and fragment, with "#"
inbetween of course, and then removing the percent encoding (for
non-hierarchical URLs query appears
13 matches
Mail list logo
