Re: A List Apart: Articles: Prefix or Posthack

On Fri, Jul 9, 2010 at 3:16 PM, Aryeh Gregor <Simetrical+w3c@gmail.com> wrote:
> On Fri, Jul 9, 2010 at 12:02 AM, L. David Baron <dbaron@dbaron.org> wrote:
>> As much as possible, we want to avoid authors putting Gecko-specific
>> content on the Web.  Authors who are using -moz-box-shadow should
>> also be using box-shadow; if they're not, they're writing
>> Gecko-specific CSS (and perhaps some additional WebKit-specific CSS,
>> etc., alongside it, which is still hostile to any new entrants in
>> the browser space along with any omitted existing browsers).
>
> On the other hand, if every -moz-box-shadow is supposed to be
> accompanied by an identical box-shadow, what's the point?  A mess like
> "-moz-box-shadow: foo; -webkit-box-shadow: bar; box-shadow: baz" is
> only tolerable so long as foo, bar, and baz could legitimately be
> different.  What you seem to be saying is that "-moz-box-shadow: foo"
> should *always* be accompanied by "box-shadow: foo" in stylesheets.
> Then why not drop the prefix entirely?  It adds no information to the
> markup.
>
> I thought the point of prefixes was so that we wouldn't have lots of
> pages using a particular syntax before it's finalized and therefore
> making it impossible to change.  But that's exactly what you propose
> authors do, use the unprefixed property before it's finalized.  What's
> the goal of prefixes then?  Only to signal to authors that the
> property is unstable and so scare them off from using it if they
> aren't willing to have their pages break, so the bad syntax isn't used
> so widely and thus can be changed more easily?  Prefixes seem like a
> poor means to that end -- you could do that without requiring so much
> repetition.
>
> Also, what do you expect authors to write for the unprefixed property
> if there are multiple conflicting syntaxes supported in different
> browsers for the unprefixed property?  If I needed "-moz-box-shadow:
> foo; -webkit-box-shadow: bar" to get the same effect in Mozilla and
> WebKit, with foo != bar, am I supposed to do "box-shadow: foo" or
> "box-shadow: bar"?  (Practically speaking, the former, since WebKit
> will continue to support the prefixed version . . .)
>
> I don't see that it's reasonable to argue that authors should use
> unprefixed properties when no browser implements them, and possibly no
> browser ever *will* implement them with the syntax you're using.  If
> the syntax changes so that your declaration is still valid but means
> something different, your page very well might render worse than if
> you didn't use the property at all.

At this point I think it's valuable to bring up the concept of mix-ins
again, as expressed in the LESS CSS compiler at
http://www.lesscss.org.

Vendor prefixes are valuable, but they're annoying.  Mix-ins let us
authors hack around the annoyance without harming the value.  As a
bonus, they aid in maintainability - if a vendor-specific prefix
*does* change underneath them, the author just needs to change it in
the mixin definition, not all over their code.

~TJ

Received on Friday, 9 July 2010 22:37:34 UTC