Re: [whatwg] New URL Standard

[Alexandre Morgaut]

Thanks Anne, I'd appreciate to be able to easily get a URLUtil interface from a 
string UTL without doing some nasty hacks

I have a ew questions

Would the URLUtil interface replace the URL decomposition IDL attributes of 
the Location interface?
- 
http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#url-decomposition-idl-attributes
- 
http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#the-location-interface

Could the search property have a query and/or params (see tel: and fax: 
bellow) alias?

Could the search property have a key/value mapping?
ex:
http://test.com?param1=value1
- var value1 = url.search.param1
search as window.location could still be usable as a string


Shouldn't this document have references on some of the URL related RFCs:

- Uniform Resource Locators (URL)
- http://tools.ietf.org/html/rfc1738

- The data URL scheme
- http://tools.ietf.org/html/rfc2397

- Uniform Resource Identifier (URI): Generic Syntax
- http://tools.ietf.org/html/rfc3986

Should this document include a more complete list of schemes with ones that are 
more and more used in URLs?
ex:
- mailto:;
- https://tools.ietf.org/html/rfc2368
- https://tools.ietf.org/html/rfc6068
- tel:, fax:
- https://tools.ietf.org/html/rfc2806
- https://tools.ietf.org/html/rfc3966
- sms:
- http://tools.ietf.org/html/rfc5724
- tv:
- http://tools.ietf.org/html/rfc2838
Unfortunately, the URLUtil interface would not be adapted for them:
- the protocol, host, and hostname properties make sense and would work;
- the query part (search property) is used by the mailto:; and sms: URIs;
- for tel: and fax, we see parameters prefixed by ; as the ones used in 
some media types, those parameters could be found in the search property


PS:
Note that the fax: scheme could be supported in a form or via XHR to send PDF 
documents, postcript document, HTML documents with their potential CSS print...
But that would be another discussion

On 21 sept. 2012, at 17:16, Anne van Kesteren wrote:

 I took a crack at defining URLs: http://url.spec.whatwg.org/

 At the moment it defines parsing (minus domain names / IP addresses)
 and the JavaScript API (minus the query manipulation methods proposed
 by Adam Barth). It defines things like setting .pathname to hello
 world (notice the space), it defines what happens if you resolve
 http:test against a data URL (you get http://test/;) or
 http://teehee (you get http://teehee/test;). It is based on the
 various URL code paths found in WebKit and Gecko and supports the \ as
 / in various places because it seemed better for compatibility.

 I'm looking for some feedback/ideas on how to handle various aspects, e.g.:

 * data URLs; in Gecko these appear to be parsed as part of the URL
 layer, because they can turn a URL invalid. Other browsers do not do
 this. Opinions? Should data URLs support .search?
 * In the current text only a select few URLs support host/port/query.
 The rest is solely path/fragment. But maybe we want mailto to support
 query? Should it support host? (mailto supporting e.g. host would also
 mean normalising host via IDNA toASCII and friends. Not sure I'm fond
 of that.)
 * Advice on file URLs would be nice.
 * IDNA: what are your plans? IDNA2003 / IDNA2008 / UTS #46 / something
 else? It would be nice to get agreement on this.
 * Terminology: should we align the terminology with the API or would
 that just be too confusing?

 Thanks!


 PS: It also does the query encoding thing correctly for the first time
 ever in the history of URL standards although the wording can probably
 be improved.


 --
 http://annevankesteren.nl/





Alexandre Morgaut
Wakanda Community Manager

4D SAS
60, rue d'Alsace
92110 Clichy
France

Standard : +33 1 40 87 92 00
Email :alexandre.morg...@4d.com
Web :  www.4D.com

[whatwg] [canvas] CanvasRenderingContext2D with addPath, currentPath

[Dirk Schulze]

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 path, or let 
you replace the current path with another Path object (not live)?

These could possibly also replace clip(Path), fill(Path), stroke(Path),  
drawSystemFocusRing(Path path...), isPointInPath(Path path…).

It needs to be clarified what happens for this case:

var path = new Path();
path.lineTo(20,20);
ctx.currentPath = path;
ctx.fill();

The pendant on CanvasRenderingContext2D:

ctx.beginPath();
ctx.lineTo(20,20);

would do a moveTo(20,20) internally. Should Path do the same? This problem 
exists for fill(Path path) at the moment as well, if I did not miss a line. Qt 
for instance adds a moveTo(0,0) at the beginning if no current point was 
specified, other platforms behave differently.

Greetings,
Dirk

Re: [whatwg] [canvas] Path object

[Charles Pritchard]

We proposed this in the public-canvas-api working group.

There may be some tricky parts with transforms.

From an implementation perspective, createPath (returns opaque CanvasPath) and 
beginPath(CanvasPath) is the easiest and most direct. The tricky part happens 
when you're in a loop with transforms as: rotate(15); beginPath(createPath()); 
will rotate another 15 degrees because the transform is applied twice.

Of course, if you've worked with canvas and pattern before, you're used to 
handling inverse transforms when appopriate.

-Charles

On Sep 22, 2012, at 9:17 PM, Elliott Sprehn espr...@gmail.com wrote:

 I was looking at the canvas Path API and had some concerns. In
 particular it's inconsistent with the rest of canvas:
 
 We already have CanvasGradient and CanvasPattern in the global
 namespace, so this should probably be called CanvasPath.
 
 We also have createLinearGradient() and createPattern(), but this new
 thing is new Path.
 
 Could we get some consistency here? Like adding new CanvasGradient()
 (or a createPath() method) to match up with Path and renaming this
 thing CanvasPath?
 
 - Elliott