Prefix and posthack - designing for evolvability

[Ernest Prabhakar]

Dear CommonJS crowd,

I was really struck by this analysis of how browser-specific prefixes for "in-development" features can promote interoperability and evolvability:

A List Apart: Articles: Prefix or Posthack

http://www.alistapart.com/articles/prefix-or-posthack/

We ought to praise vendors for using prefixes, and indeed encourage them to continue. Beyond that, I hold that prefixes should become a central part of the CSS standardization process. I do this not for the love of repetition, but out of a desire to see CSS evolve consistently. I believe that prefixes can actually accelerate the advancement and refinement of CSS.

This reminds me of a proposal I saw here earlier, where implementors initially implement modules in their own namespace, and only later move them into the "common" namespace:

I believe so firmly that vendor prefixes are a good thing that I’m prepared to take the next logical step: Vendor prefixes should be made more central to the standards process. They should be required of newly implemented properties and should be the mechanism by which interoperability is declared.

Over time, the vendors refine their implementations in response to bug reports and clarifications by the Working Group. Eventually, the Working Group decides that two of the three are fully interoperable. Those implementations then get to support the bare...

So what happens when a new implementation debuts? It uses the prefix in its first release, no matter how many interoperable implementations already exist... Then, as soon as the Working Group deems the implementation of -ms-text-curlinteroperable, the prefix can be dropped in the next release

While a short-term pain, this seems like it would allow people to implement aggressively. All it would require (I think) is some "meta-API" to help scripts decide which prefix to load modules in that are still evolving.

Thoughts?

-- Ernie P.

[Kris Kowal]

On Mon, Jul 12, 2010 at 10:14 AM, Ernest Prabhakar
<ernest.p...@gmail.com> wrote:

> While a short-term pain, this seems like it would allow people to implement
> aggressively. All it would require (I think) is some "meta-API" to help
> scripts decide which prefix to load modules in that are still evolving.
> Thoughts?

Complete agreement. I think Mappings actually can help here. In
another conversation, we put forth the idea of making all CommonJS
specified modules have the "common/" prefix, like "common/buffer".
Implementations like Narwhal on Node would use their own "platform
prefix" like "narwhal/buffer" or Node "node/buffer". A mapping could
be used to select the "common" implementation.

Kris Kowal

[Charles Jolley]

I think this is an awesome idea. It would make porting between platforms much easier.

-Charles

> --
> You received this message because you are subscribed to the Google Groups "CommonJS" group.
> To post to this group, send email to comm...@googlegroups.com.
> To unsubscribe from this group, send email to commonjs+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/commonjs?hl=en.
>

[Victor S]

I remember when Microsoft was trying to put their own tags into IE
everyone cried foul. Now We have 2 to 3 different tags all doing the
same thing or to a very similar effect and it's a good thing? The only
thing this will do is take power away from the standards defining
body. They will, again, be sidelined and deemed irrelevant if what
designers implement is vendor specific tags and not standard specific
tags. Where is the limit? How will this affect different browsers?
Lots of designers, including myself, are already using web-kit and
Mozilla specific tags that define CSS3 properties that IE8 does not
support. What happens when IE9 comes out, 3x the tags? This is getting
ridiculous.

- V

On Jul 12, 1:14 pm, Ernest Prabhakar <ernest.prabha...@gmail.com>
wrote:

> Dear CommonJS crowd,
>
> I was really struck by this analysis of how browser-specific prefixes for "in-development" features can promote interoperability and evolvability:
>

> A List Apart: Articles: Prefix or Posthackhttp://www.alistapart.com/articles/prefix-or-posthack/

[Marco Rogers]

There is a major difference this time around I think. Website owners
and users are much less tolerant of sites that don't work across a
range of popular browsers. Nobody wants to use vendor specific
features that introduce a huge divergence in the behavior in different
browsers. I think the idea here is that browser venders would be able
to roll out *their implementation of a proposed specification*. This
would allow the industry to vet it, provide feedback. And it would
help the standards community lock down a spec based on real usage
rather than just educated speculation.

That's my impression. There are certainly still drawbacks to the
prefix approach. But it's a better idea than what has come before.

:Marco