Re: Officially deprecating main-thread synchronous XHR?

2014-02-07 Thread Scott González
What about developers who are sending requests as the page is unloading? My understanding is that sync requests are required. Is this not the case? On Friday, February 7, 2014, Anne van Kesteren ann...@annevk.nl wrote: On Fri, Feb 7, 2014 at 6:18 PM, Jonas Sicking jo...@sicking.cc wrote:

Re: [testing] Common way to manage test bugs?

2013-12-19 Thread Scott González
(not sure the best way to reply to this list and the infra list) On Thu, Dec 19, 2013 at 9:54 AM, Arthur Barstow art.bars...@nokia.comwrote: * Bugzilla - WebApps has a single Testing component in Bugzilla for all of the specs and it has been used to report a few test case bugs [Bugs]. Using

Re: [testing] Common way to manage test bugs?

2013-12-19 Thread Scott González
I've copied the two messages (mine and Domenic's) that went only to public-webapps into the public-test-infra thread. On Thu, Dec 19, 2013 at 11:25 AM, James Graham ja...@hoppipolla.co.ukwrote: On 19/12/13 16:09, Domenic Denicola wrote: I would encourage use of GitHub for greater developer

Re: Styling form control elements

2013-12-06 Thread Scott González
On Fri, Dec 6, 2013 at 5:26 AM, Brian Di Palma off...@gmail.com wrote: If UA controls are not styleable in the manner I wish them to be and I have access to custom elements + shadow DOM, I think I would just create my own controls and use them instead of UA ones. And you'll make the

Re: Styling form control elements

2013-12-06 Thread Scott González
On Fri, Dec 6, 2013 at 10:53 AM, Brian Di Palma off...@gmail.com wrote: I did mention that these would probably be turned into reusable components in widget libraries. If they hope to be used by developers I see no reason why the issues you raised would not be addressed by those libraries.

Re: Styling form control elements

2013-12-05 Thread Scott González
Yeah, the big issues come in with using the existing elements. Given input type=date, we want to keep all of the semantics (the APIs, built-in validation, etc.), but apply custom styling. Custom styling may come in the form of CSS or it may come in the form of a completely new UI that uses JS. The

Re: Making selectors first-class citizens

2013-09-16 Thread Scott González
On Mon, Sep 16, 2013 at 4:45 PM, François REMY francois.remy@outlook.com wrote: If we add matchesSelector as an official alias to matches the same way querySelector and querySelectorAll will be aliases to query and queryAll soon, it should be possible to drop the prefixed version. This

Re: [webcomponents] Adjusting offsetParent, offsetTop, offsetLeft properties in Shadow DOM

2013-03-28 Thread Scott González
On Thu, Mar 28, 2013 at 12:49 PM, Elliott Sprehn espr...@gmail.com wrote: On Mon, Mar 25, 2013 at 2:48 AM, Dominic Cooney domin...@chromium.orgwrote: On Sun, Mar 24, 2013 at 3:50 PM, Elliott Sprehn espr...@gmail.comwrote: offsetParent is very useful to find your positioned parent, and you're

Re: window.event and Event.srcElement

2013-03-25 Thread Scott González
On Mon, Mar 25, 2013 at 3:47 PM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Mar 25, 2013 at 7:19 PM, Dave Methvin dave.meth...@gmail.com wrote: Basically, either UAs that currently implement window.event remove it or it's clearly required for web compat and hence needs to be

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

2013-03-13 Thread Scott González
On Wed, Mar 13, 2013 at 11:00 AM, Boris Zbarsky bzbar...@mit.edu wrote: In the non-hidden case, I believe .shadowRoot is how you get access. I meant in the non-hidden case. The name should make sense in terms of accessing this property. exposeRoot, hideRoot, publicRoot? Re-reading Dimitri's

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

2013-03-12 Thread Scott González
It's been a while since I looked at this spec, what are the ways in which you can get access? It seems like a name such as traversable could work well. On Tue, Mar 12, 2013 at 6:47 PM, Daniel Buchner dan...@mozilla.com wrote: What about obscured, opaque, invisible, or restricted? On Tue,

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

2013-03-08 Thread Scott González
On Fri, Mar 8, 2013 at 12:03 AM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: On 7.3.2013 19:54, Scott González wrote: Who is killing anything? Hi, given http://lists.w3.org/Archives/**Public/public-webapps/** 2013JanMar/0676.htmlhttp://lists.w3.org/Archives/Public/public-webapps

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

2013-03-07 Thread Scott González
On Wed, Mar 6, 2013 at 3:00 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/6/13 1:31 PM, Scott González wrote: but we feel the pros of exposing internals outweigh the cons. When you say exposing internals here, which one of the following do you mean: 1) Exposing internals always. 2

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

2013-03-07 Thread Scott González
On Thu, Mar 7, 2013 at 1:37 PM, Bronislav Klučka bronislav.klu...@bauglir.com wrote: Your questions about things like should scripts use closures are just derailing the conversation. I'm honestly not sure it's worth replying to any of your points. But to clarify some points I think are

Re: [webcomponents]: Making Shadow DOM Subtrees Traversable

2013-03-06 Thread Scott González
On Wed, Mar 6, 2013 at 1:12 PM, Rafael Weinstein rafa...@google.com wrote: I'm curious if jQuery or others have experienced feeling restricted because apps are depending on internals by way of having access to them via monkey-patching This is unfortunately a very real pain for jQuery. On the

Re: [webcomponents] Making the shadow root an Element

2013-02-11 Thread Scott González
There is also a discussion taking place in the jQuery bug tracker [1] related to issues arising from shadow roots not being elements. [1] http://bugs.jquery.com/ticket/13342 On Mon, Feb 11, 2013 at 6:49 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: Right now, the shadow root inside a

Re: Trialing Web Components

2012-07-09 Thread Scott González
On Mon, Jul 9, 2012 at 3:09 PM, rektide rekt...@voodoowarez.com wrote: My attempt is at: https://gist.github.com/3078187 I think you meant https://gist.github.com/3078197

Re: Proposal: Document.parse() [AKA: Implied Context Parsing]

2012-05-25 Thread Scott González
On Fri, May 25, 2012 at 3:01 AM, Rafael Weinstein rafa...@google.comwrote: -if start tag is td or td typo: th

Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-05-11 Thread Scott González
On Fri, May 11, 2012 at 7:13 AM, Henri Sivonen hsivo...@iki.fi wrote: However, I'm not strongly opposed to adding innerHTML to DocumentFragment if we also add a method on Document that parses a string using the HTML parser regardless of the HTMLness flag of the document and returns a

Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-05-10 Thread Scott González
Why is simplicity not enough of an answer? If you're developing a widget which uses templates for various portions, then as the widget developer you won't know the context for each template. You could probably figure it out by rendering the templates from top to bottom and inspecting the element

Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-05-10 Thread Scott González
On Thu, May 10, 2012 at 7:01 PM, Ian Hickson i...@hixie.ch wrote: But I'm very skeptical about creating new APIs to encourage authors to use injection-prone, non-type-checked, direct string manipulation in script to generate DOM trees. Do you realize that a very large percentage of

Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-05-10 Thread Scott González
Let's pretend that $() doesn't exist and we exposed this functionality as jQuery.createElementFromHtml(). FWIW, web authors' design aesthetics don't really match the Web platform's design aesthetic. This is why broken APIs like querySelectorAll() will be replaced by intuitive APIs like find().

Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-05-10 Thread Scott González
On Thu, May 10, 2012 at 7:15 PM, Rafael Weinstein rafa...@google.comwrote: On Thu, May 10, 2012 at 4:01 PM, Ian Hickson i...@hixie.ch wrote: If we're going to do that, then we don't need any lookahead at all. We should support literally that: parsing one element and its descendants. We

Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-05-10 Thread Scott González
On Thu, May 10, 2012 at 8:03 PM, Ian Hickson i...@hixie.ch wrote: I understand that people do this kind of thing all the time, but I've always at least assumed that everyone agreed that it was a necessarily evil because the alternatives were even worse. I had hope when we were discussing

Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-05-09 Thread Scott González
Users will surely find this annoying when they know that it can be automated. This will also result in users being tripped up on this as they learn about this feature by looking at some other code that isn't passing a context (because it doesn't need one) and then all of a sudden they hit a case

Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-05-09 Thread Scott González
Perhaps I'm missing something, but isn't foocaptionbar/caption an invalid use case? Any top-level element that needs a context can't be mixed with a text node. Are there cases where this isn't true? I don't know how the actual parsing works, but the following logic seems reasonable to me: If the

Re: [webcomponents] Custom Elements Spec

2012-05-08 Thread Scott González
On Tue, May 8, 2012 at 1:48 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: For the same reason that jQuery plugins are authored by a significantly smaller set of people than jQuery users. Significantly smaller, but not necessarily significantly more capable. *Theoretically*, every jQuery

Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events

2012-05-01 Thread Scott González
On Tue, May 1, 2012 at 5:08 PM, Boris Zbarsky bzbar...@mit.edu wrote: If we _do_ decide to specify them then their interaction with script running inside the events that changes the focus needs to be very carefully specified, since changing focus will change what cut/copy/paste behavior. I

Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events

2012-05-01 Thread Scott González
On Tue, May 1, 2012 at 6:38 PM, Ryosuke Niwa rn...@webkit.org wrote: Does the dataTransfer interface available through via paste event address your use cases? http://dev.w3.org/2006/webapi/clipops/clipops.html#fire-a-clipboard-event

Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events

2012-05-01 Thread Scott González
On Tue, May 1, 2012 at 7:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 5/1/12 6:07 PM, Scott González wrote: I recall moving focus for paste events in order to figure out what is being pasted. I believe this is common in WYSIWYG editors; a new element is created and focus is moved

Re: [webcomponents] Template element parser changes = Proposal for adding DocumentFragment.innerHTML

2012-04-25 Thread Scott González
On Wed, Apr 25, 2012 at 4:55 PM, Yehuda Katz wyc...@gmail.com wrote: https://github.com/jquery/jquery/blob/master/src/manipulation.js#L17-42 For posterity: https://github.com/jquery/jquery/blob/247d824/src/manipulation.js#L17-42

Re: [webcomponents] HTML Parsing and the template element

2012-04-24 Thread Scott González
On Tue, Apr 24, 2012 at 2:40 PM, Brian Kardell bkard...@gmail.com wrote: All that said, maybe with some time and experience I could learn to love it as DOM too... I'm really not trying to be the only one arguing endlessly about it, so unless someone backs me up on at least some point here I