<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Infrequently Noted &#187; politics</title>
	<atom:link href="http://infrequently.org/category/politics/feed/" rel="self" type="application/rss+xml" />
	<link>http://infrequently.org</link>
	<description>Alex Russell on browsers, standards, and the process of progress.</description>
	<lastBuildDate>Thu, 16 May 2013 00:07:12 +0000</lastBuildDate>
	<language>en-US</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.5.1</generator>
		<item>
		<title>Election Season</title>
		<link>http://infrequently.org/2012/11/election-season/</link>
		<comments>http://infrequently.org/2012/11/election-season/#comments</comments>
		<pubDate>Tue, 06 Nov 2012 20:44:46 +0000</pubDate>
		<dc:creator>alex</dc:creator>
				<category><![CDATA[politics]]></category>
		<category><![CDATA[standards]]></category>

		<guid isPermaLink="false">http://infrequently.org/?p=1924</guid>
		<description><![CDATA[So election season is upon us &#8212; no, not that one &#8212; elections for the W3C&#8217;s Technical Architecture Group (TAG). You might be thinking to yourself &#8220;self, I didn&#8217;t know the W3C had such a thing&#8230;how very strange&#8230;I wonder what it does.&#8221; Also, you might be wondering why I&#8217;d bother to write about a perfunctory [...]]]></description>
				<content:encoded><![CDATA[<p>So election season is upon us &#8212; no, not that one &#8212; elections for the <a href="http://www.w3.org/2001/tag/">W3C&#8217;s Technical Architecture Group (TAG)</a>. You might be thinking to yourself &#8220;<em>self, I didn&#8217;t know the W3C had such a thing&#8230;how very strange&#8230;I wonder what it does.</em>&#8221; Also, you might be wondering why I&#8217;d bother to write about a perfunctory process related to a group whose <a href="http://www.w3.org/2001/tag/doc/PublishingAndLinkingOnTheWeb-20121015.html">deliverables</a> you have probably never encountered in the wild and are fantastically <a href="http://www.w3.org/2001/tag/products/">unlikely to</a>.</p>
<p>The answer is that I&#8217;m now in the running for one of the TAG&#8217;s 4 open seats. At last week&#8217;s TPAC I <strike>was talked</strike> talked myself into running. Google has nominated me, so we&#8217;re off to the proverbial races. Given the number of condolences I&#8217;ve received since deciding to run, you might wonder why I&#8217;d do such at thing at all; particularly since the general consensus is that the TAG&#8217;s impact is somewhere between &#8220;mostly harmless&#8221; and &#8220;harmless&#8221;. I&#8217;ve never heard it described as &#8220;valuable&#8221; or &#8220;productive&#8221; in its modern incarnation, so why run? Could it be for the warmth of human contact that a weekly conference call could provide? A deep-seated but as yet unfulfilled desire to weigh in on what really irks me about how people use HTTP? Indeed not.</p>
<p>I&#8217;m running to try to turn the TAG into an organization that has something to say about the important problems facing devs building apps today; particularly how new specs either address or exacerbate those challenges.</p>
<p>Notionally that&#8217;s what the TAG does now; review specs in development and provide feedback. If you look at the current <a href="http://www.w3.org/2001/tag/products/">work items</a>, however, there&#8217;s nothing about JavaScript. There&#8217;s similarly little on DOM or the sorry state of API design at the W3C and how it is enabled by WebIDL and a broad cultural ignorance of JS. The TAG could provide advice on API design to WGs, how to think about creating a well layered platform, and how to keep webdevs in mind at all times. </p>
<p>State management gets a <a href="http://www.w3.org/2001/tag/doc/IdentifyingApplicationState-20111130">lengthy exposition</a> that doesn&#8217;t do much to uncover the challenges in designing apps that need to keep and manage state, synchronize that state in local data models, and map state onto URLs. Its a hard problem that most JS-driven apps struggle with and the TAG has no view beyond motherhood, apple pie, and pushState(). It can do better.</p>
<p>For webdevs, the TAG is a natural ally &#8212; it carries the weight of the W3Cs reputation in ways that vendor-motivated WGs don&#8217;t. It can be an advocate for building things well to reluctant managers and organizations, helping you make the &#8220;environmentalist&#8221; argument; &#8220;the web is for everyone, why are you making it bad?&#8221; It can also be a go-between for agitated webdevs and the WGs, a voice of reason and patient explanation.</p>
<p>As a talking shop, the TAG can never be expected to have power over implementations or webdevs, but it can be opinionated. It can take a stand on behalf of webdevs and call out huge problems in specs, missing work items for WGs, and build bridges to the framework authors that are doing the heavy lifting when the browsers don&#8217;t. It can also build bridges to other standards bodies that specify hugely important parts of the web platform, bringing a webdev perspective to bear. </p>
<p>I have worked inside a browser, represented Google at TC39, and have built large apps and frameworks on the web stack. I have seen firsthand how the TAG isn&#8217;t doing this important work of building bridges and jawboning on behalf of web developers. And I plan to fix it, if elected.</p>
<p>If you work at a company that is a member of the W3C, I hope to get your AC rep&#8217;s vote. If not, I would still love your support in letting AC reps from <a href="http://www.w3.org/Consortium/Member/List">the Member organizations</a> know that you support the goal of turning the TAG into an advocacy organization for the interests of webdevs.</p>
<p>If you&#8217;re <em>particularly</em> interested in this problem, I&#8217;d love your help &#8212; I&#8217;m looking for reformist-minded candidates to join me in running for the TAG. If you don&#8217;t have a sponsoring or nominating organization, send me mail or a tweet.</p>
<p><strong><em>Voting nitty-gritty</em></strong>, largely cribbed from Ian Jacob&#8217;s <a href="https://lists.w3.org/Archives/Member/w3c-ac-members/2012OctDec/0038.html">mail to a Members-only W3C mailing list</a>:</p>
<ul>
<li><b>Nominations</b>: any Member organization may nominate <em>one</em> individual to serve on the TAG. That nominating organization is expected to cover their nominee&#8217;s costs for the period of service, so don&#8217;t nominate in haste. Nominations are currently open and close on Nov 30th.
</li>
<li><b>Voting</b>: only Advisory Committee members from Member organizations can vote on the TAG elections. It&#8217;s not clear when voting starts but it ends on January 31st, 2013. So if you have an opinion about this, find your AC rep (or one from a company you think should be voting here) and let them know how you feel.
</li>
</ul>
]]></content:encoded>
			<wfw:commentRss>http://infrequently.org/2012/11/election-season/feed/</wfw:commentRss>
		<slash:comments>10</slash:comments>
		</item>
		<item>
		<title>Vendor Prefixes Are A Rousing Success</title>
		<link>http://infrequently.org/2011/11/vendor-prefixes-are-a-rousing-success/</link>
		<comments>http://infrequently.org/2011/11/vendor-prefixes-are-a-rousing-success/#comments</comments>
		<pubDate>Fri, 18 Nov 2011 14:36:27 +0000</pubDate>
		<dc:creator>alex</dc:creator>
				<category><![CDATA[openweb]]></category>
		<category><![CDATA[politics]]></category>
		<category><![CDATA[standards]]></category>
		<category><![CDATA[webdev]]></category>

		<guid isPermaLink="false">http://infrequently.org/?p=1715</guid>
		<description><![CDATA[tl;dr version: Henri Sivonen&#8217;s arguments against vendor prefixing for CSS properties focus on harm without considering value, which in turn has caused him to come to a non-sensical set of conclusions and recommendations. Progress is a process, and vendor prefixes have been critical in accelerating that process for CSS. For a while now I&#8217;ve been [...]]]></description>
				<content:encoded><![CDATA[<p><em>tl;dr version: Henri Sivonen&#8217;s arguments against vendor prefixing for CSS properties focus on harm without considering value, which in turn has caused him to come to a non-sensical set of conclusions and recommendations. Progress is a process, and vendor prefixes have been critical in accelerating that process for CSS.</em></p>
<p>For a while now I&#8217;ve been hearing the meme resurface from CSS standards folks and a few implementers that &#8220;vendor prefixes have failed&#8221;. I&#8217;d assumed this was either a (bad) joke or that it was one of those things that web developers would scoff at loudly enough to turn the meme recessive. I was wrong.</p>
<p>Henri Sivonen, Mozilla hacker extrordinare, <a href="http://hsivonen.iki.fi/vendor-prefixes/">has made the case directly and at length</a>. Daniel Glazman, co-chair of the CSS WG posted a <a href="http://www.glazman.org/weblog/dotclear/index.php?post/2011/11/16/CSS-vendor-prefixes-an-answer-to-Henri-Sivonen">point-by-point response.</a> If you have the patience, you should read both.</p>
<p>Lost in the debate between &#8220;browser people&#8221; and &#8220;spec people&#8221; is the the essential nature of what has happened with prefixes: they <em>worked</em>. From the perspective of a web developer, any first approximation of the history of vendor prefixes are <em>pure win</em>, even if only a fraction of the value that has been delivered behind them is attributable to prefixes un-blocking vendors from taking risks and shipping early.</p>
<p>Daniel&#8217;s rebuttal to Henri gets a lot of things right, but he gives in on an essential point; by agreeing with Henri that vendor prefixes are &#8220;hurting web authors&#8221; he wites off the benefits that they&#8217;ve delivered &#8212; namely the ability of vendors to get things out to devs in a provisional way that has good fallback and future-proofing properties and the ability for devs to build with/for the future in an opt-in, degradable way.</p>
<p>Rounded corners, gradients, animations, flex box, etc. are all design and experience enablers that developers have been able to take advantage of while waiting for the standards dust to settle, and thanks to W3C process, it takes a LONG time to to settle. Yes, that has some costs associated with it. Henri is very worried that browsers that aren&#8217;t keeping up quickly will be &#8220;left behind&#8221; by webdevs who use only one vendor&#8217;s prefix. But surely that&#8217;s a lesser harm than not getting new features and not having the ability to iterate. And it provides incentive for following browsers to try to make a standard happen. What&#8217;s not to love? More to the point, I just don&#8217;t believe that this is a serious problem in practice. What front-ender in 2011 doesn&#8217;t test on <em>at least</em> two browsers? Yes, yes, i&#8217;m sure such a retrograde creature exists, but they were going to be making non-portable content <em>regardless of prefixes</em>. Assuming you&#8217;re testing fallback <em>at all</em> (e.g., by testing on more than one browser), prefixes not appearing on some browser are just the fallback case. CSS FTW! Webdevs who don&#8217;t test on more than one browser&#8230;well, they&#8217;re the ones hanging the noose around the neck of their own apps. Vendor prefixes no more enable this stupidity than the existence of the <code>User-Agent</code> header. Compatibility is a joint responsibility and the best each side (browser, webdev) can hope of the other is some respect and some competence. Cherry picking egregious examples and claiming &#8220;it&#8217;s hurting the web&#8221; seems, at a minimum, premature.</p>
<p>And how did we think we&#8217;d get a good standard, anyway? By sitting in a room in a conference center more often and thinking about it harder? Waiting on a handfull of early adopters to try something out in a tech demo and never stress it in practice? That&#8217;s not a market test (see: XHTML2), it doesn&#8217;t expose developers to the opportunities and tradeoffs that come with a new feature, and doesn&#8217;t do anything to address the inevitable need to integrate feedback at <em>some</em> point.</p>
<p>Yes, we could go with Henri&#8217;s suggestion that the first person to ship wins by default, never iterate on any designs, and avoid any/all first-mover disadvantage situations, but who among the browser vendors is perfect? And what would the predictable consequences be? I can only assume that Henri thinks that we&#8217;ll end up in a situation where vendors coordinate with the CSS WG early to add new stuff, will design things more-or-less in the open, and will only ship features to stable (no flag) when they&#8217;re sure of their design. That could happen at the limit, but I doubt it. Instead, the already fraught process of adding new features to the platform will be attempted by even fewer engineers. Who wants the responsibility for having to be perfect lest you screw the web over entirely? Fuck that noise, I&#8217;m gonna go work on a new database back-end or tune something to go faster. Browsers are made by smart people who have a choice of things to be working on, and any time you see a new platform feature, it probably came about as the result of an engineer taking a risk. Many times the engineers in a position to take those risks don&#8217;t have a great sense for what good, idiomatic web platform features might be designed, so they&#8217;ll need to tweak/iterate based on feedback. And feedback is painfully hard to extract from webdevs unless you&#8217;ve made something available in a tangible way such that they can use it and discover the limitations.  Shipping things only to dev is perhaps a good idea for other aspects of the platform where we can&#8217;t count on CSS&#8217;s forgiving parsing behavior (the basis for prefixes). Syntax changes for JS and CSS seem like good examples. But for features that are primarily new CSS properties? Oy. Making the stakes even higher, reducing the ability to get feedback and iterate isn&#8217;t going to lead to a harmonious world of good, fast standards creation. It&#8217;s going to predictably reduce the amount of new awesome that shows up in the platform.</p>
<p>Prefixes are an enabler in allowing the <em>necessary</em> process of use, iteration, and consensus building to take place. Want fewer messes? There&#8217;s an easy way to achieve that: try less stuff, add fewer features, and make each one more risky to add. That&#8217;s Henri&#8217;s prescription, wether or not he knows it, and the predictable result is a lower rate of progress &#8212; advocating this sort of thing is <em>much</em> worse for the web and for developers than any of the harm that either Henri or Daniel perceive.</p>
<p>Which brings me to Henri&#8217;s undifferentiated view of harm. His post doesn&#8217;t acknowledge the good being done by prefixed implementations &#8212; I get the sense he doesn&#8217;t build apps with this stuff or it&#8217;d be obvious how valuable prefixed implementations are for work-a-day web app building &#8212; instead focusing on how various aspects of the process of prefixed competition can be negative. So what? Everything worth having costs <em>something</em>. Saying that things &#8220;hurt the web&#8221; or &#8220;hurt web developers&#8221; without talking in terms of <em>relative harm</em> is just throwing up a rhetorical smoke screen to hide behind. If you focus only on the costs but write the benefits out of the story of <em>course</em> the conclusion will be negative. In many cases, the costs that Henri points out are <em>correctly aligned</em> with getting to a better world: having to type things out many times sucks, creating demand among webdevs for there to be a single, standardized winner. Having multiple implementations in your engine sucks, creating demand from vendors to settle the question and get the standards-based solution out to users quickly. Those are good incentives, driven by prices that are low but add up over time in ways that encourage a good outcome:  a single standard implemented widely.</p>
<p>And as Sylvain Galineau pointed out, what looks like pure cost to one party might be huge value to another. I think there&#8217;s a lot of that going on here, and we shouldn&#8217;t let it go un-contextualized. The things that Henri sees as down-sides are the predictable, relatively minor, costs inherent in a process that allows us to make progress faster and distribute the benefits quickly, all while <em>minimizing</em> the harm. That he&#8217;s not paying the price for not having features available to build with doesn&#8217;t mean those opportunity costs aren&#8217;t real and aren&#8217;t being borne by webdevs every day. Being able to kill table and image based hacks for rounded corners is providing HUGE value, well ahead of the spec. Same for gradients, transitions, and all the rest. Calling prefixed implementations in the wild a bad thing needs to argue that the harm is greater than all of that value. I don&#8217;t think Henri could make that case, nor has he tried.</p>
<p>I think the thing that most shocks me about Henri&#8217;s point of view is that he&#8217;s arguing against a process when in fact the motivating examples (transforms, gradients) have been sub-optimal in <em>exactly</em> the better-than-before ways we might have hoped for! Gradients, for example, saw a lot of changes and browsers had different ideas about what the syntax should be. Yes, it&#8217;s harder to get a consistent result when you&#8217;re trying to triangulate multiple competing syntaxes, but we got to <em>use</em> this stuff, get our hands dirty, and get most of the benefits of the feature while the dust settled. Huzzah! This is <em>exactly</em>> the way a functioning market figures out what&#8217;s good! Prefixes help developers understand that stuff can and will change, and they clear the way for competition of ideas without burdening the eventual feature&#8217;s users with legacy bagage tied to a single identifier.</p>
<p>So what about the argument that there might be content that doesn&#8217;t (quickly?) adopt the non-prefixed version, or that vendors can&#8217;t remove their prefixed implementations because content depends on it?</p>
<p>To the first, I say: show me a world where 90+% of users have browsers support the standard feature and I&#8217;ll show you a world in which nobody (functionally) continues to include prefixes. That process is gated in part by the WG&#8217;s ability to agree to a spec, and here I think there&#8217;s real opportunity for the CSS WG to go faster. The glacial pace of CSS WG in getting things to a final, ratified spec is in part due to amazingly drawn-out W3C process, and in part a cultural decision on the part of the WG members to go slow. My view is that they should be questioning both of these and working to change them, not blaming prefixes for whatever messes are created in the interim.</p>
<p>As for removing prefixes, this is about vendors just doing it, and quickly. But the definition of &#8220;quickly&#8221; matters here. My view is that vendors should be given <em>at least</em> as long as it took to get a standard finalized from the introduction of their prefixed version for the removal process to be complete. So if Opera adds an amazing feature behind a <code>-o-</code> prefix in early 2012 and the standard is finalized in 2014, the deprecation and eventual removal should be expected to take 2 years (2016). This has the nice symmetry of incentives that punish the WG for going slow (want to kill prefix impls? get the standard done) while allowing the vendors who took the biggest risks to provide the softest landings for their users. And it doesn&#8217;t require that we simply go all-in on the first person&#8217;s design to ship. Yes, there will be mounting pressure to get <em>something</em> done, but that&#8217;s good too!</p>
<p>The standards process needs to lag implementations, which means that we need spaces for implementations to lead in. CSS vendor prefixes are one of the few shining examples of this working in practice. It&#8217;s short-term thinking in the extreme to either flag the costs associated with them as either justifying their removal or even suggesting that the costs are too high.</p>
<p>And webdevs, always be skeptical when someone working on an implementation or a spec tells you that something is &#8220;hurting the web&#8221; when your experience tells you otherwise. The process of progress needs more ways to effectively gauge webdev interest, collect feedback, and test ideas. Not fewer or narrower channels.</p>
]]></content:encoded>
			<wfw:commentRss>http://infrequently.org/2011/11/vendor-prefixes-are-a-rousing-success/feed/</wfw:commentRss>
		<slash:comments>26</slash:comments>
		</item>
		<item>
		<title>Journey To The Center Of Prop 8</title>
		<link>http://infrequently.org/2008/11/journey-to-the-center-of-prop-8/</link>
		<comments>http://infrequently.org/2008/11/journey-to-the-center-of-prop-8/#comments</comments>
		<pubDate>Sat, 01 Nov 2008 22:37:52 +0000</pubDate>
		<dc:creator>alex</dc:creator>
				<category><![CDATA[personal]]></category>
		<category><![CDATA[politics]]></category>
		<category><![CDATA[prop8]]></category>

		<guid isPermaLink="false">http://alex.dojotoolkit.org/?p=831</guid>
		<description><![CDATA[The proponents of Prop 8 have argued weakly. They deserve to loose.]]></description>
				<content:encoded><![CDATA[<p>Contents after the jump due to the political (and highly contentious) nature of the content.</p>
<p><span id="more-831"></span></p>
<p>A couple of weeks ago I had the great honor to officiate the beautiful civil ceremony that saw my dear friends Caryl and Amy married. As <a href="http://tharpo.com">Jennifer</a> and I were married just a bit earlier in the year, we were well aware of the logistical nightmare that is a wedding. Given everything else that was going on in the lives of our friends at the same time, the timing of the wedding seemed likely to give one of them a heart attack&#8230;but there really wasn&#8217;t much of a choice. It&#8217;s now or potentially never.</p>
<p>The shortened timeframe that many of our friends and colleagues have planned their weddings on is due to the impending vote on <a href="http://en.wikipedia.org/wiki/California_Proposition_8_(2008)">California&#8217;s Prop 8 ballot initiative</a> which seeks to amend the California constitution to take away the right of same-sex couples to marry. For those who haven&#8217;t been following along closely, earlier this year the California Supreme Court ruled (<a href="http://www.latimes.com/news/local/la-me-gaymarriage16-2008may16,0,6182317.story">on a split vote</a>) that <a href="http://www.leginfo.ca.gov/.const/.article_1">Article 1</a> makes denying the rights of civil marriage to any set of consenting adult citizens illegal.</p>
<p>This makes some people crazy, irate, or both.</p>
<p>Not a week after our friends were married, Jennifer and I were folding laundry while listening to the radio. <a href="http://www.kqed.org/epArchive/R810150900">An episode of the call-in show Forum came on which had the &#8220;pro&#8221; and &#8220;con&#8221; sides both represented by articulate advocates</a>. I can&#8217;t recommend strongly enough that you listen to the broadcast, since it gets to the core arguments for and against Prop 8 in an incisive way.</p>
<p>Fundamentally, the prop-Prop 8 argument (i.e., anti gay marriage) is that it&#8217;s always been done this way, that gay marriage in some way undermines straight couples and the family structure, and that change would make those who are against gay marriage feel like they are being discriminatory. The first argument I have some sympathy with, particularly as it relates to the appropriateness and timing court decisions. When courts are significantly ahead of public opinion regarding grants of negative rights, the potential to exacerbate existing social frictions is very real. This can harm lots of people on both sides of an issue. That, on balance, however hasn&#8217;t been sufficient grounds to continue to deny major groups of Americans rights before (think women&#8217;s suffrage and equal pay). Arguments based on the idea that something has always been done a particular way therefore run counter to the subversive and radical nature of the American system. We base interpretation of the law on argumentation (informed, of course, by common morality). Courts are not allowed to re-enforce the status quo simply to preserve a group&#8217;s sense of comfort. Groups looking for a particular remedy must provide an argument that squares with the Constitution. It&#8217;s worth remembering that documents which suggest that everyone is entitled to equal rights under the law aren&#8217;t common in human history. There is nothing so American, then, as to suggest that what makes us different is that we explicitly recognize the rights of groups not like ourselves. After all, it&#8217;s the only way to guarantee that those groups respect and preserve the rights of others as well.</p>
<p>That, then, leaves the arguments that gay marriage (or, more broadly, an understanding that being gay is not criminal) will cause the decay of straight relationships and marriages. As a married straight person, I find this argument ridiculous. Let me be very clear on one point: when we as a society recognize the rights of our minorities, we do not create those minorities from whole legal cloth. The people who that Prop 8&#8242;s supporters want to take rights away from <em>have always existed</em>. It&#8217;s not as though the recognition that they have been oppressed for centuries somehow makes that continued oppression right. Nor does it suddenly cause more people to &#8220;become gay&#8221;. I&#8217;ve had gay and lesbian friends since high school, and never once has it caused me to question my own sexual orientation. Given the deep conversations I&#8217;ve had with my friends over the years, it&#8217;s clear to me that being gay is as much of a choice as being black is. Those who oppose civil gay marriage seem to believe that they aren&#8217;t doing any harm to anyone by denying others rights. What this means to me as someone who grew up in a <em>very</em> conservative part of the country but nevertheless has nearly always had gay and lesbian friends is that Prop 8&#8242;s supporters <em>are simply denying the harm they have caused to their own communities, families, and co-workers</em>. It is simply willful ignorance to wish away ten percent of the population. Likewise, their argument assumes that some among us don&#8217;t deserve equal protection because somehow granting them standing in court will diminish the standing of straight couples. I have yet to see any compelling evidence of this.</p>
<p>Lastly, the argument that children will somehow see their parents as bigoted and that parents have a right not to be viewed as prejudicial by their families strikes me as particularly foolish. Progress requires that we change, and change requires that we acknowledge that what came before was not optimal. This is true no matter how you define &#8220;progress&#8221;. To effect real change, abolitionists required an understanding in the populace that slavery was wrong. Similarly, prohibitionists had to build a large constituency against alcohol consumption in order to get the eighteenth amendment passed. In both cases the question of moral right and wrong needed to be settled independently of the question of legal and illegal, but settling that issue was a pre-requisite for social change and legal action. In each case, large sections of the people fundamentally disagreed with the majority well past when the issue appeared &#8220;settled&#8221; in the law. That is a question of private morality and the fact of the disagreement is what animates our political and legal processes. Without recognized disagreements, how can there ever be progress in <em>any</em> direction?</p>
<p>So the question for those concerned parents comes sharply into focus: do those parents agree with <em>every single other thing</em> taught in public schools? If they don&#8217;t (and I&#8217;m guessing parents who are &#8220;Yes on 8&#8243; voters aren&#8217;t big on, say, biology, astronomy, and the scientific method), how do they handle the the other disagreements? What makes this one so much different? Have those parents abdicated the teaching of morality to the public schools on every other front? And why do they assume that they won&#8217;t be able to exercise their rights to have their kids exempted from teachings they don&#8217;t agree with on religious grounds?</p>
<p>Lets get to the real center of this: religious groups have a right to be prejudiced against <em>whomever they please</em>. It&#8217;s a fundamental part of being an American that you are allowed to believe whatever you want. It&#8217;s not, however, a recognized right that you will never be presented with evidence of your disagreement with others. Hiding behind a cloak of forced ignorance and denial is intellectually and morally dishonest. If the church to which I belong wants to argue that gay marriage is sinful, wrong, or in some other way morally bankrupt, then it needs to have the courage of its convictions to make that case forcefully in the world <em>as a moral and ethical case</em>. Isn&#8217;t it the church&#8217;s job to convert those who disagree with it to the church&#8217;s way of viewing the world and in so doing change their behavior? If religious organizations think that it&#8217;s wrong for gays and lesbians to practice their rights under the law, it&#8217;s incumbent of the church <em>to convince gays and lesbians of that</em>, not the rest of us.</p>
<p>When the church over-reaches and instead attempts to legislate from the pulpit, both the genius of the constitution and the authority of the church are jeopardized. Arguing the civil implications on the moral grounds is simply inconsistent with how our law operates, and the church knows it. Worse, what if the church were to win such a fight on that basis? Who then interprets where to go from there? Lots of faiths with many differing views all reject religious gay marriage&#8230;which of those faiths should be consulted next time? All of them? What if they don&#8217;t agree? It&#8217;s a far better thing that the Church understand the distinction between church and state in order to preserve the independence of its message from the corrupting influence of power. History is crystal clear on this point.</p>
<p>More to the point, though, if you wish to be prejudiced why should it somehow cause distress that others disagree? Isn&#8217;t the mere fact of the disagreement an opportunity to make a case? And if the argument doesn&#8217;t hold up for the majority of the population, doesn&#8217;t it deserve to loose? For churches and communities of faith to attempt to argue that the institution of holy matrimony (as distinct from civil marriage) is in any way affected by the equal protection provisions of the law is dishonest and misrepresents their interest in the political process. To argue that it would be best if society simply didn&#8217;t recognize the difference between the law and what the church teaches is also disingenuous, dishonest, and dangerous to the church.</p>
<p>I cannot support Prop 8, and I urge you not to either. Please vote &#8220;no&#8221;. The proponents have not fielded good arguments that show harm and have resorted to incredulous arguments which bear no resemblance to the truth. The opponents have sought and won the protection of the law. Taking that away &ndash; which is what is on the ballot &ndash; is unconscionable.</p>
]]></content:encoded>
			<wfw:commentRss>http://infrequently.org/2008/11/journey-to-the-center-of-prop-8/feed/</wfw:commentRss>
		<slash:comments>6</slash:comments>
		</item>
		<item>
		<title>Fascinating Data</title>
		<link>http://infrequently.org/2008/07/fascinating-data/</link>
		<comments>http://infrequently.org/2008/07/fascinating-data/#comments</comments>
		<pubDate>Tue, 15 Jul 2008 22:02:18 +0000</pubDate>
		<dc:creator>alex</dc:creator>
				<category><![CDATA[economics]]></category>
		<category><![CDATA[politics]]></category>

		<guid isPermaLink="false">http://alex.dojotoolkit.org/?p=691</guid>
		<description><![CDATA[Note: this post is far afield of my usual discussions. In the interest of not distracting those who read this blog because I usually discuss web-oriented things, the content of the post is beyond the jump. Via Mark Thoma, the SF Fed&#8217;s briefing numbers look really odd. The inflation expectation numbers look to depend on [...]]]></description>
				<content:encoded><![CDATA[<p><b><em>Note</em></b>: this post is far afield of my usual discussions. In the interest of not distracting those who read this blog because I usually discuss web-oriented things, the content of the post is beyond the jump.</p>
<p><span id="more-691"></span></p>
<p>Via Mark Thoma, <a href="http://economistsview.typepad.com/economistsview/2008/07/frbsf-the-econo.html">the SF Fed&#8217;s briefing numbers look really odd</a>. The inflation expectation numbers look to depend on an extreme version of the commonly held assumption that workers have lost their collective bargaining power, thereby removing the wage/price linkage that caused so much damage in the 70&#8242;s. That might be good for &#8220;the economy&#8221; (as defined by what&#8217;s good for bankers), but if true, it seems bad for you and me.</p>
<p>What it means to you and I is that our economy has a chance of beating the rap on the fundamental inability of private markets (bankers) to judge risk accurately only because some percentage of our annual incomes will be shaved off <em>and there&#8217;s nothing we can do about it</em>. And that <em>is</em> the good news. Put another way, we&#8217;re staring down the last of the Bush Administration&#8217;s regressive taxes and we just have to take it. The well-off pay a 17%-ish percent maginal tax rate on investment income, while those in &#8220;the productive economy&#8221; (the people those stimulus checks are designed to help out) pay well above that on every additional dollar they earn. Of course, it&#8217;s basic economics that if you are in a situation in which you spend more of your marginal income than you save, then any tax on consumption hits you much harder than those who can afford to save. So prices increases without attendant wage increases hurt the middle and lower classes, particularly when the price increases <em>aren&#8217;t</em> related to &#8220;core&#8221; inflation. When &#8220;core&#8221; inflation goes up, it really starts to squeeze asset values, but non-core inflation simply implies that it costs more to buy things like food, fuel, and all of the other daily necessities. While &#8220;core&#8221; inflation seems a good metric to talk about projected long-term inflation rates and linkages and <a href="http://krugman.blogs.nytimes.com/2008/05/31/embedded-vs-non-embedded-inflation/">embedding</a>, its effects aren&#8217;t the ones currently being felt by Americans.</p>
<p>Inflation is generically decried most heartily by the wealthy because it hurts them by reducing the real interest rate on savings, i.e. it reduces the return on assets invested. But not all inflation is created equal. The current situation is laying bare the difference between the average person&#8217;s concerns about non-core inflation (the price of gas) and economists concerns about asset allocation (what&#8217;s the rate of return on investment?). Put tersely: the current bout of inflation is hurting the people who can least afford it and those who <em>can</em> afford it are using the occasion to decry policies which they personally dislike even if their relationship is tenuous to the current trouble. There seems to be a lack of proportionality at work in the public dialog which I find deeply unsettling. Where did our conception of an adversarial press corps go?</p>
<p>The odd take-away is that inflation isn&#8217;t so bad when it&#8217;s tied to increases in productive output and income for those most at risk and when those increases promote stability, a fact that the &#8220;Washington Consensus&#8221; missed time and time again in its disastrous <a href="http://www.amazon.com/Stability-Growth-Macroeconomics-Liberalization-Development/dp/0199288143/ref=sr_1_2?ie=UTF8&#038;s=books&#038;qid=1216157215&#038;sr=8-2">large-scale experiments in emerging economies</a>. If those most at risk of income shocks are insulated by very low unemployment rates and a system that allows those in trouble to keep most of their (minimal) wealth in times of trouble (employment insurance, bankruptcy laws that don&#8217;t strip people of fixed assets, etc.), then inflation is a tax that hurts the rich more, who incidentally are much more able to cope with such effects.</p>
<p>But inflation like we&#8217;re experiencing? It&#8217;s of a different sort. Non-core inflation is still in-check, which is good, but headline inflation is hurting those least able to cope at a rate not seen in decades. It&#8217;s the last, grandest, &#8220;fuck you&#8221; of the current administration&#8217;s policies to those who need to work for a living. Logic and <a href="http://delong.typepad.com/sdj/2008/07/partisan-econom.html">data suggest that voting for regressive taxes isn&#8217;t in my interest</a>, or nearly anyone else&#8217;s. Why then does a party looking to cling to power field <a href="http://www.johnmccain.com/">bumbling fools</a> who <a href="http://www.washingtonpost.com/wp-dyn/content/article/2008/07/13/AR2008071301659.html">stand up for regressive taxation when logic, electability concerns, and basic math skills</a> make plain how foolish that really is?</p>
<p>I&#8217;m a &#8220;right tools for the job&#8221; kinda guy. John McCain&#8217;s economic and fiscal policy proposals certainly are <a href="http://news.google.com/news?client=safari&#038;rls=en-us&#038;q=mental+recession&#038;ie=UTF-8&#038;oe=UTF-8&#038;um=1&#038;hl=en&#038;sa=X&#038;oi=news_result&#038;resnum=1&#038;ct=title">making him look like a tool</a>, but absolutely the wrong one.</p>
]]></content:encoded>
			<wfw:commentRss>http://infrequently.org/2008/07/fascinating-data/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
	</channel>
</rss>
