- From: Eduard Pascual <herenvardo@gmail.com>
- Date: Fri, 3 Jul 2009 13:17:50 +0200
First of all, let me start with a disclaimer: I am NOT a lawyer. Do not take any of this post as legal advise, it is based only on common sense and on some years of web authoring experience. There are a few basic points to keep in mind: - First: the <small> element has some purpose, and the HTML5 spec needs to describe it, just like it describes that <p> is for paragraphs and <img> is for images. - Second: there are some kinds of legal text that are appropiate to put within <small>, while there are some that aren't. - Third: there is a very thin line between telling web authors which tools are provided by the language to mark up different kinds of text (such as legal text) and what would be legal advise about how to include legal text on a website. We need a spec that does the former but not the latter, and that's a real challenge. Now, let me go through Andrew's last mail and I'll add my suggestion based on all of this by the end of this mail. On Thu, Jul 2, 2009 at 9:25 PM, Andrew W. Hagen<contact2009 at awhlink.com> wrote: > The text from the current spec is, "Small print is typically > legalese describing disclaimers, caveats, legal > restrictions, or copyrights. Small print is also sometimes > used for attribution." > > By suggesting it is typical, that implicitly encourages people > to use small print for legal text. Then it may be appropriate to remove the word "typical". > One of HTML 5's design principles is to take the predominant > practice of what people are doing on the web, and turn that > into the standard that all HTML 5 authors should follow. > > Certain sections in the spec are normative or non-normative. > It does not make sense for the HTML 5 spec to make a non- > normative comment in a normative section. Furthermore, it is > fallacious to argue that something is not "encouragement" > but is "normative." > > Leaving any suggestion in the HTML 5 spec that legal text > typically is, could be, or should be in small print could do > a disservice to anyone reading the spec. Then we should avoid referring to legal text as a whole, and simply point out the most obvious cases where <small> is right or wrong, maybe even encouraging authors to ask for legal advice for the not so obvious cases. > Take a hypothetical example. Joe is the owner-operator of > SmallCo, a building contractor. Joe decides to create a web > site for his business. Being technically proficient, he > consults the HTML 5 web site. He reads how the <small> > element is typically used for disclaimers, etc. On his one- > page web site, he posts the following notice: > > <p>Your 100% satisfaction in the work of SmallCo is > guaranteed. <small>Guarantee applies only to commercial > buildings. </small></p> > > Joe gets a new customer from the web site. The customer has > him build a residential house. Joe does the job. The work is > done well, but the customer is not 100% satisfied. The > customer wants various changes that Joe does not consider > necessary. Joe and the customer have a serious dispute. The > customer claims that $45,000 worth of work must be performed > for the customer to be 100% satisfied. Joe claims that his > obligations are already fulfiled, and the 100% satisfaction > guarantee does not apply to the customer's job because his > residential house is not a commercial building. They take > their dispute to court. > > In this particular case, the disclaimer Joe posted on his > web site becomes a hotly disputed issue. The judge takes > special note that Joe had his disclaimer in small print. Due > to the law of the particular jurisdiction they are in, Joe > loses. Joe now must perform a great deal of work for no pay, > or pay the customer $45,000 to hire another contractor. The > financial fortunes of SmallCo and of Joe have taken a > terrible turn for the worse. Joe feels like the HTML 5 spec > gave him bad advice. It's clear that, despite the spec would currently encourage this example's markup, it is not a good choice. IMHO, either of these should be used instead: <p>Your 100% satisfaction in the work of SmallCo is guaranteed. (Guarantee applies only to commercial buildings.)</p> or <small>Your 100% satisfaction in the work of SmallCo is guaranteed. (Guarantee applies only to commercial buildings.)</small> (In the second case, the disclaimer should be at least as enforceable as the guarantee itself, because they are both in small print: either they are both enforceable, or neither is; but again don't take my words as legal advice). > Whether legal text may properly appear in small print has > been the subject of numerous lawsuits of greatly significant > value, at least in American law. The implicit encouragement > to use small print takes the lexicographical mandate of > "seeing what people are doing on the web and then making > that the standard" too far. It should be impossible for > anyone reading a tech specification to think that they are > getting legal advice. Yet that is not the case in the > current HTML 5 spec. There are *some* cases where small print can be appropriate. Since the <small> element formal description says "The small element represents small print or other side comments.", it should be appropriate for such cases. The best example here are copyright notices: since any work is automatically protected by copyright on most countries, and it can be registered for further protection without any requirement to include such notices, the notice itself doesn't need any kind of enforceability: the reader should already expect pages to be copyrighted, and the (c) notices just provide a bit of extra detail (such as year, copyright holder, and sometimes additional licensing details). > The current situation in the spec is really bad. As it reads > currently, the spec encourages fraud. This should not be > acceptable considering how much of a benefit HTML 5 will be > otherwise. Agreed. > Additionally, the word "legalese" has a strongly negative > connotation . Using the term "legalese" as a stand-in for > any legal text implies that all legal text is suspicious or > useless at best. The spec should not sit in judgment on the > law. Espousing a vaguely anarchical political point of view > is OK, but that should not be part of HTML 5. I'm not sure if the word "legalese" was intended to refer to all kinds of legal text, or just the "suspicios or useless" ones. In any case, a more accurate wording would help. > What should be done is to remove all references to the law, > legalese, and such from the small element section. If people > want to put something legal in a small element, let them > make their own choice. Let them come up with that generally > bad idea on their own, or perhaps in consultation with their > own attorneys who can take responsibility for their error if > the use of the small element causes some problem. What the > law actually says will vary according to your jurisdiction. I have to disagree here. There are still some forms of legal text that would be at home within a <small> element, and the spec somehow needs to describe that this would be allowed. > The problem with a <legal> element would be that it does not > correspond to any discrete set of text. If a web page > becomes the subject of a court case, the court is likely to > look at any part of the web page it thinks is relevant, not > just the part contained in a <legal> element. Thus, the > rationale for a <legal> element would not carry through to > the real world. For example, the following would not result > in an effective legal defense: > > <legal>SmallCo guarantees 100% satisfaction</legal> > <small>except for residential buildings</small> What about something like this? <legal>SmallCo guarantees 100% satisfaction <small>except for residential buildings</small></legal> (Note that the <small> would still be inside <legal>). Anyway, this probably depends on the final font size of the text, and on the jurisdiction where it is evaluated, so <legal> actually solves nothing. > Furthermore, we should not create a <legal> element in > anticipation that in the future at some undetermined point > it is conceivable that some legislature will somehow connect > the legal status of text on a web page to its appearance in > a <legal> element. It's too speculative. That would prove > unworkable anyway. A <legal> element would add complexity to the spec without any immediate benefit. Something like <p class="legal"> or <small class="legal"> (depending on each case) would be equally descriptive and works on current browsers. > To sum up, legal text generally should not be in small print, > because legal text is important and should be easy to read. The exact > legal consequences of legal text in small print will vary > depending on the facts of the case and on the jurisdiction. > The HTML 5 spec should not make assertions, either normative > or non-normative, about legal matters. The HTML 5 spec is > going to be a terrific advance, and removing this thorn from > its side will only improve it. It looks like you are generalizing over the set of legal texts, rather than the set of web documents. For what I have seen, the proportion of legalese suitable for small print (such as copyright notices) is quite higher in the web than in other contexts. With all this, here is my specific suggestion: First, leave the formal description "The small element represents small print or other side comments." as is: IMHO it is accurate and simple, and that's quite enough to ask from a spec. Next, replace the note that reads "Small print is typically legalese describing disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution." with something like this: "Small print is often used for *some* forms of legal text and for attribution. Defining which kinds of legal text should be on small print, however, is out of the scope of HTML." This makes clear that HTML (technically) allows using <small> to put legal text (or anything else) in small print, but it doesn't encourage any specific usage of small print. Regards, Eduard Pascual
Received on Friday, 3 July 2009 04:17:50 UTC