[whatwg] Questions regarding Path object

[Dirk Schulze]

On Nov 12, 2013, at 7:19 AM, Elliott Sprehn <esprehn at chromium.org> wrote:

> On Mon, Nov 11, 2013 at 2:52 PM, Dirk Schulze <dschulze at adobe.com> wrote:
> 
>> ...
>> 
>> 
>> The SVG WG would like to start using the 'Path' object for its objects as
>> well. We'd like this to be a generic object that can be used by other parts
>> of the web platform.
>> It would be strange to require a canvas context just to create pathh.
>> 
>> 
>> I'd like to again say I don't think this thing should be called Path. Lots
>> of other things have "Paths", like maps, file systems, urls, why does the
>> drawing one get to take the global namespace?
>> 
>> Given that there's a bunch of new objects with Drawing as the prefix, I
>> think we should name this DrawingPath like DrawingStyle and friends.
>> 
>> No.
> 
> Then I object to us shipping this in Chrome. Bleeding on the global scope
> with such a generic name ignoring all the other reasonable uses of the word
> Path is not good for the platform. It's not forward thinking, and it's
> confusing for developers.

No one is stopping you from objecting to ship it in Blink. I personally do not see any reason to diverge the web platform just because “Path” is a term that is also be used within the string “FilePath” or “URLPath". It seems rather obscure to add such a relation, since it is widely excepted that a path is a geometry if it doesn’t have a prefix that indicates otherwise. The naming topic was discussed too many times already and we always came back to Path. Safari on iOS and Mavericks ships with Path as well now. So it is your decision to block progress on the web platform or just stick to the naming.

Greetings,
Dirk

> 
> Why is your one use case more important than FilePath, URLPath and MapPath?
> Why do all the other APIs get prefixes and yours doesn't?
> - E