Re: Offline transcript

Y u no use IRC? :) comments inline…  

--  
Marcos Caceres


On Wednesday, December 19, 2012 at 4:09 PM, Brian Kardell wrote:

> Hey everyone... Clint and I have a lot of in-depth discussions online via skype and I always feel like they are lost and then only later realize that others weren't included in the details of them. Clint and I decided to post the transcript of this one and invite other comments re: forward compatibility of prollyfills and author prefixing:
>  
> [12/18/12 12:45:30 PM] bkardell: prollyfills... you agree that they should be forward compat via prefix?
> [12/18/12 12:56:27 PM] Clint Hill: i'm not sure
> [12/18/12 12:57:29 PM] Clint Hill: to be more clear: Yes. But I have reservations about yet-another-prefix
> [12/18/12 1:00:54 PM] bkardell: oh boy
> [12/18/12 1:01:21 PM] bkardell: but dude... the rationale of all of this was that the problem with prefixes are that they are tied to a browser implentation
> [12/18/12 1:01:41 PM] bkardell: how can you prollyfill something that is so early as if it were native - you just cant
> [12/18/12 1:02:11 PM] bkardell: dude - marcos tweeted that article, did you make any adjustments to it after our convo?
> [12/18/12 1:02:42 PM] Clint Hill: no ....  
>  
> I was going to write something about the lifecycle in a different post.
> [12/18/12 1:03:01 PM] Clint Hill: the prefix question feels like the guns question. The answer to the problem of guns is not "more guns"
> [12/18/12 1:03:51 PM] Clint Hill: if we come up with "x-" that certainly fixes the browser coupling. But it does nothing to change the problem of "prollyfill -> native" transition.
> [12/18/12 1:04:18 PM] bkardell: I dont know why that is a problem per-se
> [12/18/12 1:04:42 PM] bkardell: if you write with a prollyfill and it works for you your biggest concern should be that it doesn't break out from underneath you
> [12/18/12 1:04:59 PM] bkardell: given browser improvements, it will generally speaking, only get better over time
> [12/18/12 1:05:28 PM] bkardell: when a stable API is available and a prollyfill emerges, you could port it to a pollyfill if you desired
> [12/18/12 1:05:36 PM] bkardell: and the pollyfill should be reasonably easy to write
> [12/18/12 1:05:52 PM] bkardell: since it is basically just an unprefixing of the last known good prollyfill
> [12/18/12 1:06:06 PM] Clint Hill: that code change I guess is what I call the "problem"
> [12/18/12 1:07:38 PM] bkardell: I totally disagree with that assessment unless you can come up with a magic way to guarantee that the native API will match your original - which you can't
> [12/18/12 1:08:03 PM] Clint Hill: wait ...
> [12/18/12 1:08:10 PM] bkardell: you also cant guarantee that there are no surface changes between version 1.0.0 and version 1.1.0 of your prollyfill
> [12/18/12 1:08:17 PM] Clint Hill: "native API will match your <prollyfill>" ????
> [12/18/12 1:08:20 PM] bkardell: that's why prollyfills rock

This is most of the time impossible. Things that can be done with script already are generally not added to the platform…. though sometimes, vendors pave the cowpaths.    
> [12/18/12 1:08:32 PM] bkardell: ok, let's take an example from history
> [12/18/12 1:08:42 PM] bkardell: "matches" in css selectors level 4
> [12/18/12 1:09:08 PM] bkardell: this has been implemented in almost every browser now as a prefixed thing called 'any'
> [12/18/12 1:09:21 PM] bkardell: so msAny, webkitAny, etc
> [12/18/12 1:09:55 PM] bkardell: and the surface might not ultimately match the signature of the draft either
> [12/18/12 1:10:08 PM] bkardell: a draft was more or less available in 2000
> [12/18/12 1:10:20 PM] bkardell: what we ultimately get in 2014 or beyond won't match that
> [12/18/12 1:10:58 PM] bkardell: but we could have had a prollyfill in 2000 and that would have been great - it could have evolved names, signatures, versions, etc - all without problem and without risk of it breaking
> [12/18/12 1:12:59 PM] bkardell: prollyfills let us help evolve standards by: a) seperating them from the browser b) making them author-opt'in and versioned c) keeping our code working into the future without risk of it breaking -- all of these d) widen the audience and potential use-cases where we can use them way beyond what can be done in the traditional model
> [12/18/12 1:24:40 PM] bkardell: no?
> [12/18/12 2:22:19 PM] Clint Hill: sorry - stepped away to a meeting
> [12/18/12 2:27:58 PM] bkardell: np... you can respond whenever :)
> [12/18/12 2:32:00 PM] Clint Hill: so agreed on all your points. none of your points however presume the need for a prefix. the matches/any example is a historical artifact to point out as issue that prefixes bring - but does not insinuate the need for prefixing now.

Agree (at least in DOM land). There are ways around this.  

if( thing is already there) then abort… otherwise, prollyfill.  
>   
> prollyfill can use "desired to be" syntax without the need of a prefix. the prollyfill can introduce the syntax as it will be and a library to assure that syntax works (parser plays this role). upon native implementation it's a matter of "dropping the parse & script".  
> [12/18/12 2:37:18 PM] bkardell: wait ... huh?
> [12/18/12 2:37:38 PM] bkardell: there can be only one :any() or :has() signature - right?
> [12/18/12 2:37:49 PM] Clint Hill: yes
> [12/18/12 2:38:01 PM] bkardell: you agree that you cannot guarantee what that will be until it arrives?
> [12/18/12 2:38:03 PM] Clint Hill: 1 that is drafted and desired to be prollyfilled
> [12/18/12 2:38:20 PM] Clint Hill: today you cannot
> [12/18/12 2:38:24 PM] Clint Hill: but with a prollyfill you can
> [12/18/12 2:38:29 PM] Clint Hill: that's what we want to change
> [12/18/12 2:38:31 PM] bkardell: so what happens when you do :any() and then they actually implement a native :any with a different signature or even meaning?
> [12/18/12 2:38:44 PM] Clint Hill: you did so without a prollyfill framework.
> [12/18/12 2:38:52 PM] Clint Hill: that's what happens without nExt Web.
> [12/18/12 2:39:18 PM] Clint Hill: WITH a prollyfill framework you end up working towards a signature
> [12/18/12 2:39:26 PM] bkardell: yes, absolutely
> [12/18/12 2:39:38 PM] bkardell: towards being the key word there
> [12/18/12 2:39:46 PM] Clint Hill: so ... if that's agreeable ... what benefit does a prefix bring?
> [12/18/12 2:41:11 PM] bkardell: man I just dont get where you are getting this from suddenly - I so thought we were on the same page with this
> [12/18/12 2:41:50 PM] bkardell: "any" as an example... I could have two competing drafts of it
> [12/18/12 2:42:04 PM] bkardell: they have different signatures
> [12/18/12 2:42:23 PM] Clint Hill: ok - stop right ther
> [12/18/12 2:42:33 PM] bkardell: one of them (or maybe even none of them) will eventually get a native impl
> [12/18/12 2:42:41 PM] Clint Hill: yah - but stop
> [12/18/12 2:42:42 PM] bkardell: you cant know which
> [12/18/12 2:42:43 PM] bkardell: ok go
> [12/18/12 2:44:30 PM] Clint Hill: 2 prollyfills - built and delivered with nExt Web framework that provides devs tools to author and publish the work. Drafts/docs/standards lifecycle etc.
>  
> What's important is not how to "prefix" these rather what's important is that the consuming author has a way to point to the prollyfill implementation/version they want.  
>  
> consuming authors would _always_ use the word "any". the only thing they opt-in with is to point to an implementation and version ---- just like Hitch.
> [12/18/12 2:44:59 PM] Clint Hill: IMO - we can do it all without a prefix.
> [12/18/12 2:45:04 PM] bkardell: ok so look
> [12/18/12 2:45:11 PM] bkardell: you have something that looks like this
> [12/18/12 2:45:30 PM] bkardell: :any(basicSelector...)
> [12/18/12 2:45:36 PM] bkardell: and another that looks like this
> [12/18/12 2:46:19 PM] bkardell: :any(state,basicSelector...)
> [12/18/12 2:46:46 PM] bkardell: they have different signature and different purpose
> [12/18/12 2:47:07 PM] Clint Hill: ok - 2 diff prollyfills - 2 diff signatures
> [12/18/12 2:47:09 PM] bkardell: now some day in the future we get an any
> [12/18/12 2:47:24 PM] bkardell: it may be one of those - or even a third thing
> [12/18/12 2:47:29 PM] Clint Hill: yes
> [12/18/12 2:47:45 PM] bkardell: how on earth do you automatically upgrade without breaking?
> [12/18/12 2:48:01 PM] Clint Hill: :)
>  
> how does prefixing "fix" it?
> [12/18/12 2:48:07 PM] bkardell: serious?
> [12/18/12 2:48:34 PM] bkardell: if you wrote your code today prefixed, tomorrow it is still prefixed... if it worked yesterday, why would you assume it wouldn't work today?

This is true. It does provide safety.   
> [12/18/12 2:48:56 PM] bkardell: if you used <object> for video yesterday - it still works eventhough we now have <video>
> [12/18/12 2:49:17 PM] bkardell: if you used jquery - it still works even though we have qsa/find
> [12/18/12 2:49:43 PM] bkardell: not only that, but in both of those cases - your code from a few years ago actually got more efficient underneath you
> [12/18/12 2:50:18 PM] bkardell: that's part of the problem with prefixes today -- prefixes are experimental and they _do_ break underneath u

This is not necessarily true. Browser vendors probably will continue to support prefixes indefinitely to not break legacy content (even when they support the unprefixed version).   
> [12/18/12 2:50:36 PM] bkardell: how many css 3 tutorials have you looked at that are now borked
> [12/18/12 2:50:51 PM] Clint Hill: I write my code today: x-any(state, selector)
> tomorrow it's implemented.
> my code tomorrow still uses prollyfill due to x-any.
> it won't use native until I drop the "x-".
>  
> right?
> [12/18/12 2:51:41 PM] bkardell: right
> [12/18/12 2:51:57 PM] bkardell: and potentially match the API deltas or implementation/draft deltas
> [12/18/12 2:52:13 PM] bkardell: x- is not standard
> [12/18/12 2:52:33 PM] bkardell: in most cases, it is not even close early on - it is a mistake to pretend otherwise

I agree with the bkardell. There is no point in pretending that a prollyfill remotely standard.  
> [12/18/12 2:53:05 PM] bkardell: do you point to jquery latest or the version of jquery you used when you wrote your site?
> [12/18/12 2:53:37 PM] bkardell: most people use the version they actually tested with
> [12/18/12 2:54:10 PM] Clint Hill: counter idea -----
>  
> If I write my code today: any(state, selector)  
> If I include a lib for: any-brian-prollyfill.js it uses 1 of the 2 competing prollyfills
> tomorrow it's implemented (I'm lucky I chose the good one).
> tomorrow I drop the lib: any-brian-prollyfill.js
>  
> 1 code change in both cases but the implementation code is unchanged.
> [12/18/12 2:54:11 PM] bkardell: we need to post this log somewhere for others to read :)
> [12/18/12 2:54:48 PM] Clint Hill: if I happen to choose the loser - well that's a diff story right? changes everything anyways. prefixed or not
> [12/18/12 2:55:01 PM] bkardell: chances are you will pick the loser
> [12/18/12 2:55:45 PM] bkardell: because there will be competition and improvement... by sheer statistics it is impossible to assume that the vast majority of code will not choose the loser

Well, except if it's 50/50 :) But yeah…   
> [12/18/12 2:58:25 PM] Clint Hill: right - so there's code change beyond prefixing right?
> [12/18/12 2:58:29 PM] Clint Hill: (in losing case)
> [12/18/12 2:59:01 PM] Clint Hill: So to argue that we want prefixing in order to save you from that kind of code change doesn't make sense to me.
>  
> So again: What benefit does prefixing bring?
> [12/18/12 3:09:43 PM] bkardell: in the losing case, your code still works... in the winning case your code still works... even in the most winning case there might still be edge cases in the to-native shift that could cause your site to break

That sounds like win win win to me.   
> [12/18/12 3:10:26 PM] bkardell: am I missing something?
> [12/18/12 3:11:30 PM] bkardell: :x-any is pointing to a prollyfill ... note, not a pollyfill which has a very reasonable chance of going pretty smoothly in an auto-upgrade

Agree.   
> [12/18/12 3:12:18 PM] bkardell: if we drop :x- and just use :any, then you have some magic saying "if it's there use that" ... the vast majority - and I mean the _vast_ majority will break as native comes along... am I wrong?
> [12/18/12 3:15:59 PM] Clint Hill: let me say so that you feel better - i totally agree and understand.
>  
> I'm simply arguing that IMO we could do all this without a prefixing solution. I think Hitch was the right path with the ability to delcaratively point to an implemention for a hitch. (i know we used prefixes too).  
> [12/18/12 3:16:54 PM] Clint Hill: in other words I think this would be ideal:
>  
>  
> use "any()"  
> point to prollyfill
> when native
> drop pointer to prollyfill
> maybe point to polyfill
> [12/18/12 3:17:29 PM] Clint Hill: the risk is - I chose the really shitty one and need to change signatures etc.
>  
> that's still opt-in.
> [12/18/12 3:18:26 PM] bkardell: hmmm...
> [12/18/12 3:18:50 PM] Clint Hill: IMO - prefixing adds complexity without a benefit.

I think not screwing yourself and your users over on wrong assumptions is a big benefit.    
> [12/18/12 3:19:23 PM] bkardell: ok, let's imagine a flow for a second in which :matches was there in 2000 as a prollyfill, unprefixed
> [12/18/12 3:19:45 PM] bkardell: so we have some import or something indicating that there is a prollyfill
> [12/18/12 3:20:35 PM] bkardell: 15 years go by and now we have a native :matches which either has the same signature and does something different - or has a different signature altogether
> [12/18/12 3:21:15 PM] bkardell: my import or whatever is still there... which one gets used?
> [12/18/12 3:21:26 PM] bkardell: native or the fill I wrote against?
> [12/18/12 3:24:19 PM] Clint Hill: well ... because I've painted myself into this corner .... the prollyfill
> [12/18/12 3:24:30 PM] Clint Hill: and the only way to get native is to "drop" the fill.
> [12/18/12 3:24:47 PM] bkardell: so fill overrides native..? that feels problematic to me

Yeah. That's bad and sometimes not possible. The native implementation might not allow it.     
> [12/18/12 3:25:07 PM] bkardell: it will also cause headaches for anyone trying to read code in the future
> [12/18/12 3:25:16 PM] Clint Hill: only if you feel "opt-in" means until big brother browser bumps me out.
> [12/18/12 3:25:33 PM] Clint Hill: opt-in to me means "i declare it this way so do it this way"
> [12/18/12 3:25:51 PM] bkardell: hmm
> [12/18/12 3:26:08 PM] Clint Hill: we have said "opt-in" .... so maybe there is a confusion on my part
> [12/18/12 3:26:18 PM] bkardell: opt-in to me means "i declare it this way so do it this way"
> [12/18/12 3:26:24 PM] bkardell: I fully agree with that
> [12/18/12 3:26:30 PM] bkardell: that is my point actually
> [12/18/12 3:26:51 PM] Clint Hill: seems to me that prollyfill wins in the native vs. fill question.
> [12/18/12 3:26:52 PM] bkardell: and I think the implication the other way round is more convoluted
> [12/18/12 3:27:33 PM] bkardell: if I was reading something with :matches right now - I expect it to match the :matches I know - with all of the signature,rules and subtlety
> [12/18/12 3:27:43 PM] bkardell: I dont expect to have to go hunting for an import to find what it does
> [12/18/12 3:27:55 PM] bkardell: but if I see :x-matches ... I know what to do
> [12/18/12 3:28:29 PM] Clint Hill: hmm
> [12/18/12 3:28:34 PM] Clint Hill: i fully agree
> [12/18/12 3:28:45 PM] bkardell: i see easily that it is from a specific early fill - even which version
> [12/18/12 3:29:09 PM] bkardell: and figuring out an upgrade path (if I even care for one) should be totally documented - perhaps even scriptable

Agree.   
> [12/18/12 3:31:29 PM] Clint Hill: hmmm
> [12/18/12 3:31:33 PM] Clint Hill: really though?
> [12/18/12 3:31:53 PM] Clint Hill: the prefix gives you all that info?
> [12/18/12 3:32:05 PM] bkardell: the prefix tells you that it is imported
> [12/18/12 3:32:13 PM] bkardell: some kind of import has to tell you which version
> [12/18/12 3:32:43 PM] bkardell: given that, you should be able to pull up the draft and see the state of it
> [12/18/12 3:33:30 PM] bkardell: mapping that to what was really done should be doable...  
> if you can do it once, there is at least a chance you can lay down rules to preprocess upgrade others
> [12/18/12 3:41:00 PM] bkardell: regardless of whether you can script it - the pattern gives you the information you would need to understand how it works in its current state - and if one of those became native it should include a link to the current draft which gives you everything you need to upgrade should you choose to do so
> [12/18/12 3:41:30 PM] bkardell: the other nice thing about that is that it doesn't prevent you from keeping your old code around while starting to introduce the native version
> [12/18/12 3:41:55 PM] bkardell: :x-matches
> and
> :matches  
>  
> can coexist in the interim, which is really helpful if you are upgrading
>  
> --  
> Brian Kardell :: @briankardell :: hitchjs.com (http://hitchjs.com/)

Received on Wednesday, 19 December 2012 16:39:47 UTC