- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 19 Apr 2009 00:34:16 +0000 (UTC)
Thanks to everyone (bcc'ed) who sent in reports of typos! I've attempted to fix them, and added to the Acknowledgements the first person to report each typo found! If you sent review feedback but didn't get a reply here, never fear, it is probably still in the pile of feedback: http://www.whatwg.org/issues/#processing-model I will get to it all in due course (hopefully before October). I've only quoted the first case found for each typo in the response below. On Sat, 7 Mar 2009, Bijan Parsia wrote: > > http://www.whatwg.org/specs/web-apps/current-work/#parsing > > '''There is only one set of state for the tokeniser stage and the tree > construction stage""" > > one set of *states* Fixed. > "The stream of Unicode characters that consists the input to the tokenization > stage" > > that *comprises* Fixed. On Wed, 1 Apr 2009, Sean Fraser wrote: > > Section 4.4.3 The nav element, in your example: > > [...] > > [li>[a href="articles.html">Index of all articles[/a><li] > [li>[a href="today.html">Things sheeple need to wake up for today[/a><li] > [li>[a href="successes.html">Sheeple we have managed to wake[/a><li] > > [...] > > The closing LI are not closed. Fixed. On Fri, 3 Apr 2009, Jens Meiert wrote: > > http://www.w3.org/Bugs/Public/show_bug.cgi?id=6762 > http://www.w3.org/Bugs/Public/show_bug.cgi?id=6763 Fixed. On Fri, 3 Apr 2009, Andreas Lanjerud wrote: > > I find it confusing that ID's and attributes are not always inside > quotations. I haven't read up on how your thoughts are but in my opinion > it's better to stick to always use quotations so it validates wherever. > > See for example: 4.6.8 The dfn element: <dfn id=whatwg> The spec intentionally uses a variety of valid syntaxes in order to not mislead people into thinking that there are rules that don't actually exist, and to not take sides on the debates of what the Right Thing is. On Fri, 3 Apr 2009, Alexis Deveria wrote: > > The word "string" is misspelled as "stirng" here: > http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#attr-meta-http-equiv-refresh > It's the last word at point #18. > > Woohoo, I'm gonna be famous! I'll try to do more at a time from now on, > just wanted to secure my place in history. :) Fixed. On Fri, 3 Apr 2009, Daniel wrote: > > 1. Firefox, Opera, Safari and IE (8 and older versions) treat the > fieldset element like a block formatting root/context as defined in CSS > 2.1; Safari got a bug with collapsing margins in this case, but > otherwise, the implementations of the fieldset element are identical. I > think it should be explicitly mentioned that fieldset is to be treated > like a block formatting root. Fixed. > 2. Unlike CSS 1, CSS 2.1 doesn't allow clear to be set on inline > elements. Maybe it should be mentioned, that the br element is an > exeption to that rule, because that's how browsers implement it > (probably becausde of the old br at clear). Both HTML 4.01 and HTML 5 > suggest br to be an inline element. Fixed. On Mon, 6 Apr 2009, Francesco wrote: > > The section "8 The HTML syntax" describes that a HTML document > <i>must</i> consist of a root element, in form of an html element. > > The section "8.1.2.4 Optional tags" describes that the html element's > start and end tag <i>can be omitted</i>. On Mon, 6 Apr 2009, Lachlan Hunt wrote: > > Francesco, the root element is still present in the document, even > though its tags may be omitted from the serialisation. The start tags > are allowed to be omitted for some elements because those elements are > implied by other content. In the case of the html element, it's implied > by the presence of the head, which, if its tags are also omitted, is > implied by elements such as title or meta, etc. On Mon, 6 Apr 2009, Francesco wrote: > > Lachlan, thanks for the interesting info! > > Nonetheless my understanding of "in form of an html element" is that I > have to state explicitly the html element. It just confused me a little > bit. I've added a note in the section on omitted tags to clarify this. Does this help? On Fri, 3 Apr 2009, Greg Botten wrote: > > 1. Page 495: "Initially there is no first script (page 495)." Option: A > comma may be placed after the word "Initially" to make it consistent with > how this conjunctive adverb is used on other pages (see page 659, 428, 434). > 2. Page 666: "Initially it must be in the PCDATA state." Option: A comma > may be placed after the word "Initially" to make it consistent with how this > conjunctive adverb is used on other pages (see page 659, 428, 434). > 3. Page 428: "Initially the value mode flag (page 428) must be set to > default." Option: A comma may be placed after the word "Initially" to make > it consistent with how this conjunctive adverb is used on other pages (see > later on in page 428). > 4. Page 665: "Initially the head element pointer and the form element > pointer are both null. " Option: A comma may be placed after the word > "Initially" to make it consistent with how this conjunctive adverb is used > on other pages (see page 659, 428, 434). > 5. Page 664: "Initially the list of active formatting elements is empty." > Option: A comma may be placed after the word "Initially" to make it > consistent with how this conjunctive adverb is used on other pages (see page > 659, 428, 434). > 6. Page 662: "Initially the stack of open elements is empty." Option: A > comma may be placed after the word "Initially" to make it consistent with > how this conjunctive adverb is used on other pages (see page 659, 428, 434). > 7. Other pages with similar "Initially" comments: 614, 660, 541. Fixed. > 8. Page 221: "Finally" may warrant a comma but may not be required in a code > example Didn't fix that one but fixed another. On Sat, 4 Apr 2009, Innovimax SARL wrote: > > == Some css properties are emphasized and other not == > In 3.3.3.5. The dir attribute > [[ > CSS 'direction' and 'unicode-bidi' properties > ]] > are not emphasized as > in 4.6.21 The bdo element > [[ > requirements by implementing the CSS unicode-bidi property. [CSS21] > ]] Fixed. > You used en version for Localisation (with an S) (DONE) Fixed. > s/asychronously/asynchronously/ (STILL THERE) Fixed. On Mon, 6 Apr 2009, Todd Moody wrote: > On Fri, Apr 3, 2009 at 11:17 PM, Mohamed Zergaoui wrote: > > > > code point and codepoint (a lot of this one) > > Although both spellings are widespread, "code point" is preferable: It's > the spelling used by Unicode, Inc., and it enjoys wider usage in formal > W3C documents, IETF documents, and other authoritative resources. Fixed. On Sun, 5 Apr 2009, Kartikaya Gupta wrote: > > argments (4.8.11.1.10) Fixed. > serialis* vs. serializ* Fixed. On Sat, 11 Apr 2009, Anthony Bryan wrote: > > 2.2.1 JavsScript Fixed. > 4.9.12 targetted? Fixed. > 4.10.4.4 commited Fixed. > 5.6.1 andshow? Fixed. > 5.8.2 manfiest buu Fixed. Fixed. > 10.2.4 vertial 4x Fixed. > 10.3.1 instrinsic Fixed. > 10.4 overriden Fixed. > Also, some words with prefixes might be clearer to non-native English > readers like reresolved and misimplemented etc. re-resolved, > mis-implemented or incorrectly implemented might be better? Fixed those two. On Sat, 11 Apr 2009 liszt at coq.no wrote: > > > > > > In section 5.2.2., `chickenk?wi.soup' (with diaeresis) appears twice > > > [...], as does `chickenkiwi.soup' (without diaeresis). > > > > Fixed. > > The example is now technically correct (filename with diaeresis), but > still inconsistent: > > <a href="chickenk?wi.soup">Download our Chicken Kiwi soup!</a> > > It should probably be: > > <a href="chickenk?wi.soup">Download our Chicken K?wi soup!</a> Fixed. On Tue, 14 Apr 2009, Daniel Davis wrote: > > I hope this is not being too picky but I just noticed a small > grammatical error in "7.3.3 Message ports": > > "unentangle" occurs 3 times in this section but it is not a word. The > antonym of entangle is untangle or disentangle. Fixed. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Saturday, 18 April 2009 17:34:16 UTC