On 9/16/13 5:48 PM, Tab Atkins Jr. wrote:
That code isn't depending on matchesSelector, it's depending on
fooMatchesSelector *or* matchesSelector. As long as the former works,
it's fine - we don't need to add the latter as well.
Tab,
What's a new rendering engine supposed to do? Implement on
On Mon, Sep 16, 2013 at 2:33 PM, Brian Kardell wrote:
>> There are
>> literally zero scripts which depend on the name "matchesSelector",
>> because it's never worked anywhere. They might depend on the prefixed
>> variants, but that's a separate issue to deal with.
>
> I think Francois shared a gi
On Mon, Sep 16, 2013 at 4:29 PM, Tab Atkins Jr. wrote:
> On Mon, Sep 16, 2013 at 1:05 PM, Brian Kardell wrote:
> >> If they didn't support down-level browsers at all, then they're
> >> already broken for a lot of users, so making them broken for a few
> >> more shouldn't be a huge deal. ^_^
> >
>
On Mon, Sep 16, 2013 at 5:43 PM, Scott González wrote:
> On Mon, Sep 16, 2013 at 5:33 PM, Brian Kardell wrote:
>
>> I think Francois shared a github search with shows almost 15,500 uses
>> expecting matchesSelector.
>>
>
> As is generally the case, that GitHub search returns the same code
> dupli
On Mon, Sep 16, 2013 at 5:33 PM, Brian Kardell wrote:
> I think Francois shared a github search with shows almost 15,500 uses
> expecting matchesSelector.
>
As is generally the case, that GitHub search returns the same code
duplicated thousands of times. From this search, it's impossible to tell
> Read the thread more closely - as always, we only suggest dropping
> prefixed variants *if possible*.
Define possible.
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 b
On Mon, Sep 16, 2013 at 1:05 PM, Brian Kardell wrote:
>> If they didn't support down-level browsers at all, then they're
>> already broken for a lot of users, so making them broken for a few
>> more shouldn't be a huge deal. ^_^
>
> This seems like a cop out if there is an easy way to avoid breaki
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
On Mon, Sep 16, 2013 at 1:45 PM, François REMY
wrote:
>> Read the thread more closely - as always, we only suggest dropping
>> prefixed variants *if possible*.
>
> Define possible.
"Can be done without too many pages breaking as a result", where "too
many" is subjective.
But dealing with prefixe
On Mon, Sep 16, 2013 at 1:32 PM, François REMY
wrote:
>> Regardless of what they assumed, there's presumably a case to handle
>> older browsers that don't support it at all. If the scripts guessed
>> wrongly about what the unprefixed name would be, then they'll fall
>> into this case anyway, which
> Regardless of what they assumed, there's presumably a case to handle
> older browsers that don't support it at all. If the scripts guessed
> wrongly about what the unprefixed name would be, then they'll fall
> into this case anyway, which should be okay.
>
> If they didn't support down-level brow
On Mon, Sep 16, 2013 at 1:52 PM, Scott González
wrote:
> On Mon, Sep 16, 2013 at 4:45 PM, François REMY
> 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
On Mon, Sep 16, 2013 at 12:03 PM, Brian Kardell wrote:
> I think the responses/questions are getting confused. I'm not sure about
> others, but my position is actually not that complicated: This feature has
> been out there and interoperable for quite a while - it is prefixed
> everywhere and ca
On Sep 16, 2013 3:46 PM, "Tab Atkins Jr." wrote:
>
> On Mon, Sep 16, 2013 at 12:03 PM, Brian Kardell
wrote:
> > I think the responses/questions are getting confused. I'm not sure
about
> > others, but my position is actually not that complicated: This feature
has
> > been out there and interope
On Sep 13, 2013, at 8:26 PM, Brian Kardell wrote:
>
> On Sep 13, 2013 4:38 PM, "Ryosuke Niwa" wrote:
> >
> >
> > On Sep 11, 2013, at 11:54 AM, Francois Remy wrote:
> >
> >> For the record, I'm equally concerned about renaming `matchesSelector`
> >> into `matches`.
> >>
> >> A lot of code now
On Mon, Sep 16, 2013 at 2:51 PM, Ryosuke Niwa wrote:
> On Sep 13, 2013, at 8:26 PM, Brian Kardell wrote:
>
>
> On Sep 13, 2013 4:38 PM, "Ryosuke Niwa" wrote:
> >
> >
> > On Sep 11, 2013, at 11:54 AM, Francois Remy wrote:
> >
> >> For the record, I'm equally concerned about renaming `matchesSel
Yup. Not sure where this is in W3C DOM, but 12.2.5.1 Creating and inserting
nodes (http://www.whatwg.org/specs/web-apps/current-work/)
...
DOM mutation events must not fire for changes caused by the UA parsing the
document. This includes the parsing of any content inserted using
document.write()
was therw ever agreement on this old topic?
http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0618.htmlwhether
by de facto implementation or spec agreements? I am not seeing
anything in the draft but maybe i am missing it...
18 matches
Mail list logo
