[whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll
*The problem:*
document.querySelector and document.querySelectorAll
are long and used a lot.
Lines in the code are long.
*Proposal:*
q('.my-div')
will be equal to:
document.querySelector('.my-div)
qq('.my-div')
will be equal to:
document.querySelectorAll('.my-div')
--Leon Gilyadov.
Re: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll
So you're suggesting new globals that are bound to the document? That
sounds really bad. Also, there's no reason to suggest an alias to
querySelector() when it's much more likely that query() will be used by the
majority of developers.
On Wed, Sep 18, 2013 at 4:14 AM, Leon Gilyadov leon.gilya...@gmail.comwrote:
*The problem:*
document.querySelector and document.querySelectorAll
are long and used a lot.
Lines in the code are long.
*Proposal:*
q('.my-div')
will be equal to:
document.querySelector('.my-div)
qq('.my-div')
will be equal to:
document.querySelectorAll('.my-div')
--Leon Gilyadov.
Re: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll
The spec should only concern itself with exposing functionality. Practical
considerations such as length of code are the responsibility of the developer -
if you like to have q and qq aliases you can add them yourself at runtime,
that's the whole point of a prototyped language. Common libraries like jQuery,
prototype and Mootools expose the behaviour as $ and $$ for exactly the reason
given, no reason to impose that on every developer if they choose not to use a
library.
-Original Message-
From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org]
On Behalf Of Scott González
Sent: woensdag 18 september 2013 14:11
To: Leon Gilyadov
Cc: whatwg@lists.whatwg.org
Subject: Re: [whatwg] Proposal: q and qq for document.querySelector and
document.querySelectorAll
So you're suggesting new globals that are bound to the document? That sounds
really bad. Also, there's no reason to suggest an alias to
querySelector() when it's much more likely that query() will be used by the
majority of developers.
On Wed, Sep 18, 2013 at 4:14 AM, Leon Gilyadov leon.gilya...@gmail.comwrote:
*The problem:*
document.querySelector and document.querySelectorAll are long and used
a lot.
Lines in the code are long.
*Proposal:*
q('.my-div')
will be equal to:
document.querySelector('.my-div)
qq('.my-div')
will be equal to:
document.querySelectorAll('.my-div')
--Leon Gilyadov.
Re: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll
Aww, accidentally did a direct reply instead of replying to the list. :(
On Sep 18, 2013 7:01 AM, James Greene james.m.gre...@gmail.com wrote:
var q = document.querySelector;
var qq = document.querySelectorAll;
On Sep 18, 2013 3:14 AM, Leon Gilyadov leon.gilya...@gmail.com wrote:
*The problem:*
document.querySelector and document.querySelectorAll
are long and used a lot.
Lines in the code are long.
*Proposal:*
q('.my-div')
will be equal to:
document.querySelector('.my-div)
qq('.my-div')
will be equal to:
document.querySelectorAll('.my-div')
--Leon Gilyadov.
Re: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll
On Wed, 18 Sep 2013 16:18:05 +0200, James Greene james.m.gre...@gmail.com wrote: Aww, accidentally did a direct reply instead of replying to the list. :( On Sep 18, 2013 7:01 AM, James Greene james.m.gre...@gmail.com wrote: var q = document.querySelector; var qq = document.querySelectorAll; That doesn't work because `this` will be wrong. But you can add .bind(document) to fix that. -- Simon Pieters Opera Software
Re: [whatwg] HTML: A DOM attribute that returns the language of a node
On Wednesday 2013-05-01 01:01 -0700, Elliott Sprehn wrote: On Wed, Apr 24, 2013 at 9:22 AM, Peter Occil pocci...@gmail.com wrote: I have no objection to the name baseLang rather than language as the name of the DOM attribute. But if there isn't more interest or you decide not to add this DOM attribute, I encourage you to at least: fwiw WebKit (and Blink) implement this through CSS inheritance since you need to know the lang for all kinds of things and walking up the DOM repeatedly would be expensive. -webkit-locale is inherited by default and contains the enclosing @lang value. You can query it through getComputedStyle(node).webkitLocale. That doesn't help your custom parser though. In Gecko it's also implemented through CSS inheritance, but it's not exposed to Web content as a CSS property. (Internally it's '-x-lang', but that name isn't exposed.) We use the language for: * font selection * language-specific text-transform behavior * hyphenation (which doesn't work unless it's explicitly specified, as required by http://dev.w3.org/csswg/css-text/#hyphens-property ) -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914)
Re: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll
On Wed, Sep 18, 2013 at 7:18 AM, Niels Keurentjes niels.keurent...@omines.com wrote: The spec should only concern itself with exposing functionality. Practical considerations such as length of code are the responsibility of the developer - if you like to have q and qq aliases you can add them yourself at runtime, that's the whole point of a prototyped language. Common libraries like jQuery, prototype and Mootools expose the behaviour as $ and $$ for exactly the reason given, no reason to impose that on every developer if they choose not to use a library. This is nonsense. Usability and practicality are absolutely concerns of the spec. If libraries like jQuery need to be used for it to be convenient to develop for the platform, and everyone has different and incompatible convenience wrappers for everything, then that's a failure of the platform. (I don't think this proposal is a good idea, though.) -- Glenn Maynard
Re: [whatwg] HTML: A DOM attribute that returns the language of a node
On Wed, Sep 18, 2013 at 11:10 AM, L. David Baron dba...@dbaron.org wrote: In Gecko it's also implemented through CSS inheritance, but it's not exposed to Web content as a CSS property. (Internally it's '-x-lang', but that name isn't exposed.) We use the language for: * font selection * language-specific text-transform behavior * hyphenation (which doesn't work unless it's explicitly specified, as required by http://dev.w3.org/csswg/css-text/#hyphens-property ) It seems my earlier point about inheritance of text direction remains. Base URLs however are obsolete as only Gecko implements xml:base. If this is implemented through CSS, does it make sense to expose it through the DOM? -- http://annevankesteren.nl/
Re: [whatwg] Proposal: q and qq for document.querySelector and document.querySelectorAll
On Wednesday, September 18, 2013 at 5:27 PM, Glenn Maynard wrote: On Wed, Sep 18, 2013 at 7:18 AM, Niels Keurentjes niels.keurent...@omines.com (mailto:niels.keurent...@omines.com) wrote: The spec should only concern itself with exposing functionality. Practical considerations such as length of code are the responsibility of the developer - if you like to have q and qq aliases you can add them yourself at runtime, that's the whole point of a prototyped language. Common libraries like jQuery, prototype and Mootools expose the behaviour as $ and $$ for exactly the reason given, no reason to impose that on every developer if they choose not to use a library. This is nonsense. Usability and practicality are absolutely concerns of the spec. If libraries like jQuery need to be used for it to be convenient to develop for the platform, and everyone has different and incompatible convenience wrappers for everything, then that's a failure of the platform. (I don't think this proposal is a good idea, though.) ^ this. --tobie
Re: [whatwg] Canvas - Should setLineDash be a nullable sequence?
On Tue, Sep 17, 2013 at 10:06 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 20 Aug 2013, Simon Sarris wrote: This is minor, but it did recently break formerly-working functionality in Google Chrome, so maybe its worth a discussion. The specification reads: void setLineDash(sequenceunrestricted double segments); // default empty sequenceunrestricted double getLineDash(); This means we *cannot* use: ctx.setLineDash(null); In Chrome 28 and previous (for at least 6 months) null was an allowed value, but in Chrome 30 (at least) it switched to throwing a TypeError. I couldn't find any currently-shipping browsers that supported this, so it seems unlikely that there'd be much legacy content that depends on it. (Not saying there's none, just that it's limited in scope.) Thus, the compatibility issue here is not the only thing we should consider. (It's still a factor, just not an automatic win, as it might otherwise be.) There's certainly an advantage to failing if the input is null here -- it's more likely to catch underlying errors quicker. Instead of just getting a solid line where you expected a dashed one, you get an error with a precise line number from which to start your search. In any case, I think it would be better if setLineDash was defined in the spec as a nullable sequence, so that when setting it back to nothing to return to normal not-dashed path stroking (which could happen thousands of times in a an animation frame) less stuff gets allocated in the draw loop. A literal empty array can get optimised out by compilers, so it really shouldn't be that big a deal on the long run. I think part of the issue is that setLineDash does two things. It sets the dashing properties, but it also acts as the only way to enable/disable dashing, I think that null seems appropriate. All lines are dashed, it's just that some have an infinitely long dash with no space. Don't look at it as enabling/disabling dashing. :-) That's correct. If we ever allow a 'null', we should equate it to '[]'
Re: [whatwg] Path API feedback
On Tue, Sep 17, 2013 at 10:20 AM, Ian Hickson i...@hixie.ch wrote: On Tue, 20 Aug 2013, Rik Cabanier wrote: On Sat, 23 Mar 2013, Rik Cabanier wrote: The current path APIs suffer from conflating path segments and geometry. To fix this, I proposed to modify the API so path just describe the path segments. http://blogs.adobe.com/webplatform/2013/01/31/revised-canvas-paths/ I disagree with the premise of this post -- it's not the case that you never want to add segments. It is in fact quite common to add segments to a path -- that's what constructing a path is. I disagree. How many times does an author want to add segments to an existing path? Pretty much every time they create a path with more than one segment. Maybe I phrased that wrong. The existing path is a path that was created earlier (and could have already been used to draw). It's not often that you would want to append to such a path. Let's say an application stores a circle in a path and now want to draw a rectangle too. You propose that the application just appends the rectangle. No, not necessarily. It depends on what they want to do. If they want a single path that is constructed of a circle and a rectangle in the same way that it would be if they did: x.beginPath(); x.arc(...); x.rect(...); x.fill(); ...then yeah, they should just append the rectangle. But if they want the same effect as: x.beginPath(); x.arc(); x.fill(); x.rect(...); x.fill(); ...then they should not just append them, since as you say, it won't work. Yes, but for hit regions, you would have to calculate the area that these 2 fill operations covered. This is why we need the extra 'union' API. Also, it's not at all clear to me that there's really a distinction between a shape and a path. They're really the same thing -- sets of path segments. No. A shape is no longer a group of line segments. You *could* convert it to such a thing but that requires a bunch of complex math (ie http://www.youtube.com/watch?v=OmfliNQsk88) For now, I'm not proposing to add that to the canvas API. Once the Path API is implemented, we can add any number of features, such as adding a path so as to form the union of both paths, adding a path so as to form the intersection of both paths, etc. OK. In order to make that possible, 'addPath', 'addPathByStrokingPath', 'addText' and 'addTextByStrokingText' should be cut from the interface. The resulting 'path' will once again have no winding. This is very confusing and extremely hard to implement I don't understand why it's hard to implement. It's just the non-Path API, but stored away for future use. Right now we have two options (ignoring the text parts of the path API): concatenating path segments, and concatenating path segments after having first outlined one of them. FYI the outlining algorithm is also not correct. It suffers from the same issue that strokes are segments. Can you elaborate? (I think I may have asked already, in which case, my apologies for asking again.) I started it in http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-September/040810.html On the long run I think it would make sense to add other methods, e.g. one combining two or more paths together such that the resulting path would outline the union of the insides of the provided paths, or the intersections, or whatnot. I think that would be much more confusing and difficult to implement. I didn't come up with this on my own :-). This is done by graphics libraries that offers path manipulation support. For instance: skia: http://skia-autogen.googlecode.com/svn/docs/html/classSkPathEffect.html lib2geom: http://wiki.inkscape.org/wiki/index.php/WorkingWith2GeomFAQ Direct2D: http://msdn.microsoft.com/en-us/library/windows/desktop/dd756653(v=vs.85).aspx#path_geometries I'm confused. Are these examples of how to make confusing APIs, or examples of how the current API is confusing? Those look really, really complicated relative to what Canvas looks like today. Those are examples how path composition is defined in graphic libraries. I'm not proposing that we copy the APIs :-) None of the libraries I listed, is working on the path operations themselves (like you defined in canvas) On Thu, 5 Sep 2013, Rik Cabanier wrote: The problem happens when you call fill or stroke multiple times. [...] Now I want to create a region that covers what was drawn. [...] 'p' won't describe the same area as what was filled. Sure, for that you need a new API function, e.g. union, which as I've mentioned before, I think would be a logical addition to the API in due course. But I don't think we should add features too quickly, lest we get too far ahead of browsers. That sounds reasonable. So please remove the APIs such as AddPathByStrokingPath that rely on these difficult
