Re: Offline transcript

On Wed, Dec 19, 2012 at 12:21 PM, Clint Hill <clint.hill@gmail.com> wrote:

> I have questions/concerns regarding this part of the dialog ….
>
> Marcos said:
> > I think not screwing yourself and your users over on wrong assumptions
> is a big benefit.
>
>
>
> I want to understand this notion you have that in any prollyfill or
> polyfill we would _not_ be doing things on assumptions. I think you have an
> understanding that I don't and I think I might be wrong.
>
> It's all assumptions right? A prollyfill is assuming a signature/API to be
> standard someday. A polyfill is assuming that a standard signature/API is
> to work a certain way. Both could be totally wrong. As example I would
> point to HTML 5 input types and the polyfills that implement completely
> different UI than each other and different than what the UA might implement.
>


It seems almost inarguable though that there are more assumptions in one
than the other... By the definitions we have provided to distinguish
between the two, polyfills fill some implementation gaps in something that
is very mature and has little risk - especially if we have very high
fidelity.  On the other hand, if I publish a draft today with a prollyfill
for something like a :video-time pseudo class which allows you to write CSS
rules based on time-sync with video time, it is almost a certainty that
that exact thing will never be the standard.  Indeed, this happened
recently on the CSS group where someone proposed something like that and we
wrote up a quick proposal and prollyfill - showed it to some people who
quickly made improvements and spawned alternatives.  It was 100% valid for
the draft it was written against, and the self same code works today - why
should it break?



>
> I think the point I'm trying to make about the prefixing is … in my humble
> opinion … is that it's an additional flag on implementation code that in
> all cases is unnecessary due to better and more declarative ways of
> designating an prollyfill.
>
> Ok, how though :)


> And lastly I think I want to re-emphasize my understanding of our mission
> (because again I think I'm wrong). The idea about Extensible Web is that
> authors are in control of the experience. They would not be constricted to
> UA limitations. It seems to me that we would want a world where I can use
> "assumed" signature/API and declare which prollyfill would implement it and
> that the script assures that native implementations would not interfere in
> a detrimental way.
>
> What I described absolutely seems to put authors in control - what am I
misunderstanding?


> I defer to the smarter brains in the room; I'm just trying to provide an
> excellent authoring experience for nExt Web. Prefixing makes my skin itch.
>
>
>
>
> On Dec 19, 2012, at 9:39 AM, Marcos Caceres <w3c@marcosc.com> wrote:
>
> > 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/)
> >
> >
> >
> >
>
>


-- 
Brian Kardell :: @briankardell :: hitchjs.com