- From: Dailey, David P. <david.dailey@sru.edu>
- Date: Fri, 13 Apr 2007 00:41:05 -0400
- To: <public-html@w3.org>
(apologies in advance: this is lengthy and rather polemic. But it is by invitation, in a sense. A charter is plenty enough without adding principles or guidelines or creeds - the rest of these mores, norms, and folkways are better left for anthropologists than for legislators.)
In message http://lists.w3.org/Archives/Public/public-html/2007Apr/0017.html <http://lists.w3.org/Archives/Public/public-html/2007Apr/0017.html> ,
Maciej wrote:
>The intent for these principles is that they are pragmatic rules of thumb that must be balanced against each other, not that they have some mystical significance.
I replied:
>Okay... quoting Barbosa, then: "it's more of a guideline than an actual 'code' ..."
And then in message http://lists.w3.org/Archives/Public/public-html/2007Apr/0469.html <http://lists.w3.org/Archives/Public/public-html/2007Apr/0469.html>
Ian Hixson wrote:
>I would strongly recommend that the group nail down the design principles right away, regardless of what spec is adopted as a starting point. If you disagree with them, say so now, with clear arguments; don't leave it until someone uses one against you!
(Oops too late!)
If they are indeed more of a guideline than a "code", then my concerns as alluded to in messages http://lists.w3.org/Archives/Public/public-html/2007Apr/0460.html <http://lists.w3.org/Archives/Public/public-html/2007Apr/0460.html> and http://lists.w3.org/Archives/Public/public-html/2007Apr/0007.html <http://lists.w3.org/Archives/Public/public-html/2007Apr/0007.html> (at least one of which was plus-oned by a sympathetic onlooker) are lessened. Such spells, if based on magic alone, are easily met with counterspells.
However, given that these "aphorisms of first principle" (AFP's) have been waved again with such vigor in recent days, perhaps a more critical response is required. And why would one need to vote on "guidelines"? Their status is taking on a bit too much gravity for my comfort.
As I mentioned earlier, charters (such as of this working group) are nice. They usually are fairly brief, and clearly stated and the scope of their implications is understood by the body which issues the charter (ummm...that is, I suppose, as much as the implications of any realm of human meaning can be). I think that AFP's seek to codify portions of that realm of common sense that surrounds a charter. The motivation bespeaks a felt need to extend the charter in some way. Perhaps the charter is either insufficiently clear or powerful to accomplish some crucial goal. Yet I believe I understand the charter and its goals far better than I understand the implications and raisons d'etre of these aphoristic principles.
What can we accomplish with these AFP's that the charter does not already enable? We are convened under the terms of the charter. What more do these guidelines really accomplish?
Maciej addressed some of this:
>If we don't come to any agreement on goals and design approach, then
we will find it impossible to make productive progress on a spec.
We'll end up re-arguing the underlying issues each time we hit a
specific point of disagreement.
Okay, that makes sense. Principles like
"be nice to one another"
"try not to misquote",
"keep your threads straight m'boy"
"remember what we're trying to accomplish"
"remember to recite your aphorisms" and
"HTML is not obsolete"
are (with an exception or two) good guiding principles, that I hope most participants will abide by. I can imagine dozens of such first principles - some of which seem considerably clearer and, in the long run, more important than those we are asked to agree to.
"Ahh! If defense sets up in an O-formation, then use AFP12.7"
So let's take a look at the principles and see if there is anything ambiguous or worrisome about any:
1. DontBreakTheWeb: New versions of HTML must not break significant numbers of Web pages. In other words, browsers implementing the new version should still be able to handle existing documents.
On the surface, this seems self-evident. It seems consistent with the charter's statement:
1CH: The Group will define conformance and parsing requirements for 'classic HTML', taking into account legacy implementations;
Sometime, however, it seems to have been invoked in our discussions to mean
1ICK: Making a new browser which could do what you suggest, and at the same time handles legacy content, is too big a burden on browser developers despite whatever simplicity it may afford to authors or usefulness to users.
If you can define it, you can program it. So, so long as the syntactic requirement of some new feature can be clearly differentiated from the backdrop of existing utterances, then a grammar for that corpus can be written, following from some sort of Church's thesis.
Now one might ask: "when has anyone ever used a 'Don't break the web' to mean a 1ICK?" I don't know if there have been instances. It would be nice to have some content-analytic software (maybe based on OWL?) which would allow us to rapidly parse and sort and tabulate all this discussion (maybe we should extend our HTML - at least for this group -- into the truly "semantic" realm after all), but I would suggest the following empirical test: consider all occurrences of the usage of the "Don't break the web" mantra as invoked in HTMLWG email discussions since March 8th. I would venture to guess that a) a majority have been used by representatives of the developer community in response to suggestions from the authorial community and b) almost always the recipient of the incantation, if we were to survey that individual afterwards, will not have been persuaded by it, and more often than not will have felt intimidated by it.Observation a) would not surprise anyone, since browser developers have a clearer concept of when a halting problem presents itself than typical authors; but b) if it true, would be troublesome.
Even if none of these "icky" distortions of the most noble "don't break the web" have ever occurred, *yet*, I would deem it to be counterproductive to aims of the charter if ever it did occur. I would also deem as probable, the likelihood that it will be used in so icky a way, if it is adopted, without attaching some limitation on the scope of its purview.
2. DegradeGracefully: New versions of HTML should allow documents using them to work in user agents that don't yet support it. Authors will be reluctant to use new features that cause problems in older browsers, or that don't provide some sort of graceful fallback. Graceful degradation is most effective when it does not require special script or styling to work.
Again a veritable aphorism! How could one disagree? At first glance, the browser developers are the true experts here, since they know when things will not work in old browsers - they after all built the old browsers we authors are so fond of. But in that case, can we authors who might like to be able to propose something new be given examples of what will or won't degrade nicely?
I guess I'd need to see some use cases or examples for this "principle" to make any sense of it or to have it be useful to me. I certainly can't vote for something I don't understand. I tried cobbling together a use case of my own:
<ul>
<li type="1">a new type of tag - childless:
<artichoke wisdom="null">
</li>
<li type="1">a new type of tag - with #text child:
<artichoke wisdom="null">Artichoke leaves</artichoke>
</li>
<li type="1">an old tag with new attributes:
<table glue='csv'>
1,2,3,4,5
2,3,4,5,6
4,5,6,7,8
</table>
</li>
</ul>
New types of tags, with and without children, old types of tags with new types of attributes... is that what we mean by stuff which will not look good in older browsers? I don't know.
I tried the above in IE, FF and Opera (I wish I had a Mac) - and yes it was different in all three browsers - but nothing I would not expect. The table example above was something that was dismissed perhaps in perpetuity on grounds of "ungraceful degradation" (http://lists.w3.org/Archives/Public/public-html/2007Apr/0376.html <http://lists.w3.org/Archives/Public/public-html/2007Apr/0376.html> ) Heck, the degradation doesn't look that bad to me. It doesn't look like a table, but realistically who would expect it to? Any time one writes using a new feature, one expects it to look funky in older browsers. <layer> used to look pretty good. <div style=position:absolute> used to look pretty bad.
I think this aphorism needs to have a bit more substance for me to know exactly what we are trying to avoid here. Just as we are encourage to have specificity in our proposals for new HTML features, the sort of meta-proposals deserve at least as much fleshing out.
3. DontReinventTheWheel <http://esw.w3.org/topic/DontReinventTheWheel> : If there's already an implementation with a sufficient userbase that exposes a widely used feature, prefer specifying that feature as opposed to inventing something new for the same purpose.
The name of this thing is a bit provocative. The Rouleaux triangle is, as I understand it, a wheel that is not round that has found interesting applications - as I recall somebody at Sandia was using it for something practical. A nice example http://mathworld.wolfram.com/ReuleauxTriangle.html <http://mathworld.wolfram.com/ReuleauxTriangle.html/>
With the above argument one can say
a) why have <video> when we have JavaScript + JPG?
b) Why have <video> since the patent on animate GIF seems to have expired?
c) Why have <canvas> when we have <body onmousemove="f()"> plus JavaScript?
d) Why have <canvas> when we have <svg>?
e) Why does WHATWG not just focus on fixing things instead of inventing new things?
Maciej responded to some of this when he said:
I don't think it would lead to dismissing such features, just
checking what existing implementations do. It probably would be used
to dismiss a proposal to make a new direct mode graphics API that is
incompatible with <canvas> as implemented by Mozilla, Opera and
Safari, or to do copy-paste in a way that widely differs from what
Internet Explorer, Safari, Mozilla and Opera implement.
Sure. I think the principle is something worth keeping in mind like "be nice to people", but it seems like the argument feels better when we make it at someone, but not so fun when someone makes it at us. If a new wheel solves a problem better, then it is a good new wheel.
Please "Do invent new wheels!" would be a better bumper sticker and having visited Apple headquarters a month or two ago, it would work better with the slogans on the walls there, from my aesthetic perspective. Sometimes there are better ways of doing old things. This would tend to curtail a natural progression toward simpler ways of doing things.
4. PaveTheCowpaths <http://esw.w3.org/topic/PaveTheCowpaths> : When a practice is already widespread among authors, consider adopting it rather than forbidding it or inventing something new.
I happen to like this one. If these darn principles become a creed of some sort - rather than just friendly guidelines, best be warned I'll be using this like a mad ant whenever somebody fusses about improper uses of tables and blockquote. Yessirree, I think I will. Do we really wish to sanction mad-ant mode? Nah. And I really am bluffing here, for the sake of dramatic hyperbole. I really do like this one. But other than as a platitude what good is it really? Is it worth having a vote on platitudes? Each of us can point to a nice dozen pages of platitudes about software design and development and collaborative effort and some of the gems to be found there are brilliant. Better to share such things as hints and suggestions than as grounds for dismissal.
5. EvolutionNotRevolution <http://esw.w3.org/topic/EvolutionNotRevolution> : Revolutions sometimes change the world to the better. Most often, however, it is better to evolve an existing design rather than throwing it away. This way, authors don't have to learn new models and content will live longer. Specifically, this means that one should prefer to design features so that old content can take advantage of new features without having to make unrelated changes. And implementations should be able to add new features to existing code, rather than having to develop whole separate modes.
Again, what looks revolutionary to one person looks only evolutionary to another and vice versa. Yeah, sure most of what this says is sensible, though the catch-phrase grates on my nerves like fingernails on a chalkboard. And I'm pretty sure I don't really understand the last sentence, to tell you the truth. I would like HTML to become much more ambitious than I think WHATWG is aiming at.
See http://lists.w3.org/Archives/Public/public-html/2007JanMar/0555.html <http://lists.w3.org/Archives/Public/public-html/2007JanMar/0555.html> by way of explanation.
I think much of what I'm talking about there cannot be done currently using HTML and from what I can gather on the basis of discussion to date, most of it cannot be done with WHATWG's HTML. If all we are really interested in is patching up broken incompatable implementations of existing HTML, then why all the new stuff in WHATWG? And so long as we are considering new stuff, why limit our vision to that? Where does any of this hook into the semantic web?
I much prefer "HTML is not obsolete" as a bumper sticker to "evolution not revolution" and if we're not careful, folks might just go live in Second Life and forget about this HTML stuff anyhow. "HTML - the next gopher" would be a sad epitaph.
[Some sort of Bob Dylan quote probably belongs here.]
6. SolveRealProblems <http://esw.w3.org/topic/SolveRealProblems> : Changes to the spec should solve actual real-world problems. Abstract architectures that don't address an existing need are less favored than pragmatic solutions to problems that web content faces today. And existing widespread problems should be solved, when possible.
I'm sorry. I know I shouldn't have problems with this but I do. Can someone give me a real world example of a problem (deserving of the moniker "problem") which is not a real world problem? Suppose in some possible world, we are able to generate problems for which the mapping between the possible and the putative "actual" world does not exist. Then we have a possibly infinite class of such problems that have no bearing on the actual world. But how might we actually instantiate that set without transporting an instance into the real world? Must we not invoke some sort of axiom of imaginary choice?
What sort of imaginary problems are we protecting ourselves from here?
I surmise that what this means is "back up what you propose with a needs analysis"? If that's what we mean then, let's say that. But that already seems to be a general dictum of the culture of the W3C, so I'm not sure we need an aphorism that sends some of our brains into funny directions to help us remember it.
7. Separation of Concerns. - The ambiguity of the word "semantic" is troublesome see http://lists.w3.org/Archives/Public/public-html/2007Apr/0167.html <http://lists.w3.org/Archives/Public/public-html/2007Apr/0167.html> in which Karl Dubost suggests:
I think we should avoid to use the word semantics to qualify the type of content the element/attribute is supposed to mark up. That would help to avoid debates based on misunderstanding.
(I believe I sort of seconded that in a reply
http://lists.w3.org/Archives/Public/public-html/2007Apr/0189.html <http://lists.w3.org/Archives/Public/public-html/2007Apr/0189.html> ).
On the other hand the group's charter makes use of the term in what looks like the same way as these proposed design principles, so who knows? Does that constitute partially contesting a principle?
8. Support world languages.
Of course. I am troubled by how little representation we appear to have of languages outside the Indo-European family in our group here. I can imagine putting in motion a whole series of studies about the comparative linguistics of graphemic notational conventions. How is emphasis indicated in Mayan script? How is pig-Latin pronounced in Tagalog? What various markups does ancient Chinese use to indicate document revision? I can't imagine doing these studies correctly, though, in the time frame we have allocated. Nor can I imagine, based on the relatively circumscribed issue of abbreviation vs acronym, that any two people could agree on the scope of what our work would be. I'm not contesting the point, just thinking it is a bit ambitious for now.
9. AvoidNeedlessComplexity <http://esw.w3.org/topic/AvoidNeedlessComplexity> : Simple solutions are preferred to complex ones, when possible. Simpler features are easier for user agents to implement, more likely to be interoperable, and easier for authors to understand. But this should not be used as an excuse to avoid satisfying the other principles.
I particularly like this one. Would it not suggest that we eliminate the Proposed Design Principles / AFP's. The working group's charter is a whole lot simpler. Oh, I forgot the last sentence. It specifically excludes our ability to use it to get rid of all the others. Darn. I guess I only like it if we get rid of the last sentence.
David Dailey
Received on Friday, 13 April 2007 04:40:58 UTC