Re: [polymer-dev] PSA: PointerEvents and PointerGestures are being replaced by polymer-gestures, breaking changes for pointer* events
Which release are the implementations for *hold*, *release* etc. planned for? On Friday, April 25, 2014 9:34:20 PM UTC+2, Daniel Freedman wrote: No, there is no concept of an over event, because it requires hit-testing per movement, which is very expensive. On Fri, Apr 25, 2014 at 11:42 AM, Aleksandar Rodic aleksa...@google.comjavascript: wrote: Thanks for the update! Is there a PointerGesture equivalent to 'pointerover' event? Seems like 'track' event only fires when mouse button is pressed. On Tuesday, April 15, 2014 6:12:51 AM UTC-7, Rick Byers wrote: Thanks Daniel. I know this was a tough decision for the Polymer team. I'm glad we can continue to collaborate on Pointer Events and the polyfill! Rick On Mon, Apr 14, 2014 at 11:58 PM, Daniel Freedman dfr...@google.comwrote: Yes, there are no plans to move it anywhere else. On Apr 14, 2014 8:18 PM, Jacob Rossi jacob...@microsoft.com wrote: Will the polyfill continue to live here: https://github.com/polymer/ PointerEvents? *From:* Daniel Freedman [mailto:dfr...@google.com] *Sent:* Monday, April 14, 2014 4:42 PM *To:* Rick Byers *Cc:* polymer-dev; public-poi...@w3.org *Subject:* Re: [polymer-dev] PSA: PointerEvents and PointerGestures are being replaced by polymer-gestures, breaking changes for pointer* events It is my hope that when PointerEvents has a few more native implementations, then polymer-gestures can transition to being a consumer of PointerEvents only, and we can reinstate the polyfill for other browers. To that end, I plan to maintain the PointerEvents polyfill to follow the spec as it evolves (thankfully there have been few breaking changes since the WG started). Unfortunately, the polyfill's performance penalty on mobile is an information problem, and not one I see workarounds for in the near to medium term. Target finding seems to be expensive no matter which way I try to slice it, and mobile already operates at a tremendous speed disadvantage. I do not intend this change to be negative signal on the part of PointerEvents, but an (unfortunate) acceptance of the practical realities of mobile devices and polyfill performance. On Mon, Apr 14, 2014 at 4:23 PM, Rick Byers rby...@google.com wrote: +public-pointer-events What does this mean for other consumers of the PointerEvents polyfill? Will it be effectively orphaned? On Apr 14, 2014 7:15 PM, Daniel Freedman dfr...@google.com wrote: Hi Polymer users, We recently had a big perf investigation of mobile use cases and found that our gesture layer was not performant enough to get 60 FPS[1]. For this reason, I have created the polymer-gestures library which gesture events in a mobile-performant way. In the next release, polymer-gestures will replace (the now deprecated) PointerGestures, and PointerEvents will be removed from the default build. These are the supported events of polymer-gestures: - down - up - Same target as down, provides the element under the pointer with the relatedTarget property - trackstart - track - Same target as down - trackend - Same target as down, provides the element under the pointer with the relatedTarget property - tap - Targets the nearest common ancestor of down and up.relatedTarget - Can be prevented by calling any gesture event's preventTap function - flick * - hold * - holdpulse * - release * - pinchstart * - pinch * - pinchend * * = Not yet implemented If you listen for pointerdown, pointermove, pointerup, pointerover, pointerout, pointerenter or pointerleave, you will need to change your code. If you require an event for every movement of the pointer, you can use the track event. This change was not made lightly, but only after careful consideration of device constraints and lack of cross-browser PointerEvent implementations. The Polymer team still believes that PointerEvents are the best technical solution for handling user input, but mobile use cases are too important to be gated on native implementations. I apologize for the churn. [1]: The big culprit was the gymnastics the PointerEvents polyfill had to make to be spec compliant and target the correct elements with ShadowDOM. In particular, the encapsulation mechanics of ShadowDOM made target finding for pointermove very expensive, requiring recursive elementFromPoint calls. Another large chunk of time was wasted on having gesture recognizers listen for dispatched, normalized pointerevents. Polymer-gestures will use the lower-level events directly without spinning up the DOM event system N times each pointer movement. Follow Polymer on Google+: plus.google.com/107187849809354688692 ---
Re: [polymer-dev] Re: The complaint: Web Components are XML
I fully agree Ryan - thanks for posting.
On Tue, Apr 29, 2014 at 7:23 PM, 'Scott Miles' via Polymer
polymer-dev@googlegroups.com wrote:
Well said and 100% correct IMO.
On Mon, Apr 28, 2014 at 6:12 AM, ryan.g...@nthpenguin.com wrote:
To the notion that the OP and others brought up regarding the desire for
people to 'not use Web Components to make the whole site'... isn't that the
point? Turning the entire application into granular, reusable, well
encapsulated components that can be easily composed into larger specialized
components in a declarative manner is pretty much the whole idea here. For
me, that's been the promise of the web platform all along, and the great
frameworks embrace this (Enyo, Facebook React, Polymer, X-tags). Markup is
a natural expression layer for this compositional way of working. Enyo
achieves their declarative composition with JSON mixed into the component's
imperative declaration, and that's fine too, but the beauty of using markup
is that you can easily embed and compose at the document level. That's
HUGE! Please don't view that as even remotely a negative. Being able to
compose semantic markup (that comes with rich functionality) at the
document level brings clarity to the web development process. It brings the
expression of what you want the app to do closer to the implementation of
making it happen.
Not only do I think people should be embracing this, I can attest to the
power of doing so. Before Web Components was a glean in the collective eyes
of the W3C, I have been using one widget/component based framework or the
other, often writing my own (https://github.com/theVolary/feather). Once
you get practiced in thinking through how to break the application up into
small chunks of compose-able functionality, you will be pleasantly
surprised at just how often you get to reuse your components in contexts
other than the one you initial created it for. It also becomes a heck of a
lot easier to re-organize things when requirements change.
There is nothing wrong with markup, nor with using a component based
approach to create the entire application.
On Friday, April 25, 2014 1:35:22 PM UTC-5, Rob Dodson wrote:
You can look at the content of an import using the dev tools
On Fri, Apr 25, 2014 at 11:07 AM, rvin...@gmail.com wrote:
Hey all, great discussion! I totally agree with Patrick's Point #2
I learnt more from viewing source of how a big website implements cool
effects than reading tutorials on the internet. Is it possible that the
HTML imports being used can be viewed as well?
On Thursday, April 3, 2014 11:24:03 PM UTC+5:30, Rob Dodson wrote:
re: point no. 2
This is already the case today. Here's a screenshot of the markup
generated by
gmailhttp://html5-demos.appspot.com/static/cds2013/index.html#19.
That code is the byproduct of some framework just spitting out DOM as a
substrate. So they're already sort of obfuscating but hopefully you
wouldn't need to spew out all of that DOM if whatever they were building
was just encapsulated in Shadow DOM and wrapped in a Custom Element.
On Wed, Apr 2, 2014 at 3:15 PM, pat...@patrickmetcalfe.com wrote:
My opinion on Web Components has two sides.
1. HTML is about being accessible to *everyone* and as a self-taught
programmer I believe the div soup is inaccessible to people who are
interested in how a website works (Don't tell me you haven't been there
before. I've learned so many things from Cmd+Opt+U) or even new coworkers
who have to an encyclopedia and an expert to understand how a site is
laid
out before he can do anything, just look at this page. d
*ivdivdiv...forever...*
2. I'm worried devs will make tags that totally obfuscate their code
for performance gains or to make it unreadable to outsiders (opposite of
an
open web see #1 above). Imagine if Google was filled with tags along the
lines of g-weibvlqbeqbiubqkjdbiuqbek that only Google can understand.
This has serious ramifications beyond my programmer-friendly point in
terms
of accessibility, SEO , etc. Its important to remember that HTML should
be
readable and comprhenible without a user-agent stylesheet hiding the tags
and stuff.
On Sunday, October 20, 2013 10:57:41 AM UTC-5, Rob Dodson wrote:
I think the most frequent gripe I hear about Web Components is that
they look like XML and that totally freaks people out. I can definitely
imagine my own horror if I were to open up a client project and top to
bottom was all custom elements that I knew nothing about.
My own opinion is that they're almost like jQuery plugins. I don't
see much difference in:
div class=fancy-dropdown/div
$('.fancy-dropdown').dropdown();
and
fancy-dropdown/fancy-dropdown
and just like jQuery plugins, they're great if used in moderation
but *horrible* if they constitute the bulk of your site. I realize
that's not a very accurate analogy but I think it gets at my main point
which is If it does
[polymer-dev] equivalent to angularjs attribute directive?
is there a polymer equivalent to angularjs attribute directives? i want to define an 'autosave' attribute, which i can add to arbitrary elements, and will automatically save their contents to local storage. is there a way to do this with polymer? Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/f3b35c62-e908-4128-9daa-77ab08bf12c5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[polymer-dev] equivalent to angularjs attribute directive?
Untested, but I suspect you can pull this off by setting up a base element that defines the autosave attribute and behavior - and have all/most of your custom elements inherithttp://www.polymer-project.org/docs/polymer/polymer.html#extending-other-elementsfrom it On Wed Apr 30 2014 at 2:12:54 PM, James Campos james.r.cam...@gmail.com wrote: is there a polymer equivalent to angularjs attribute directives? i want to define an 'autosave' attribute, which i can add to arbitrary elements, and will automatically save their contents to local storage. is there a way to do this with polymer? Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/f3b35c62-e908-4128-9daa-77ab08bf12c5%40googlegroups.comhttps://groups.google.com/d/msgid/polymer-dev/f3b35c62-e908-4128-9daa-77ab08bf12c5%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAKc-BFhPqt2a91yYBFroRA54LFqc0EY8LiunhWad95aGuw35xw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [polymer-dev] equivalent to angularjs attribute directive?
Hi James, I built something similar to Angular directives for Dart called behaviors. It's based on mutation observers and Element.matches and you could pretty easily port it to JavaScript. The repo is here https://github.com/justinfagnani/behaviors.dart An announcement with some details is here: https://plus.google.com/108970026289541541510/posts/EjdR14bA7Dj Cheers, Justin On Apr 30, 2014 4:12 PM, James Campos james.r.cam...@gmail.com wrote: is there a polymer equivalent to angularjs attribute directives? i want to define an 'autosave' attribute, which i can add to arbitrary elements, and will automatically save their contents to local storage. is there a way to do this with polymer? Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/f3b35c62-e908-4128-9daa-77ab08bf12c5%40googlegroups.comhttps://groups.google.com/d/msgid/polymer-dev/f3b35c62-e908-4128-9daa-77ab08bf12c5%40googlegroups.com?utm_medium=emailutm_source=footer . For more options, visit https://groups.google.com/d/optout. Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAEKsHmBH_g9DeNRY2p7xQ-zwir%3D93uw1H6%2BRegt9W_0uLF%2BFAg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[polymer-dev] is there a way to disable shadow DOM?
I'm just interested in the custom elements part. Shadow DOM inter fears with some third party libraries I want to use. is there a way to disable this? Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/6b231fbf-bf77-40a1-babd-1f6cda507771%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[polymer-dev] Re: is there a way to disable shadow DOM?
sometime a third party library need access to the sub DOM from outside the custom element. On Wednesday, April 30, 2014 7:55:09 PM UTC-5, rua...@gmail.com wrote: I'm just interested in the custom elements part. Shadow DOM inter fears with some third party libraries I want to use. is there a way to disable this? Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups Polymer group. To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/1b075422-0b93-4a12-a4ab-88f2fbc0689e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
