Re: review of HTML5 differences from HTML4

Hi Anne,

Firstly, thank you for taking the time to address my comments. Some 
follow-ups below.

On 6/8/10 2:53 PM, Anne van Kesteren wrote:
> Hey Marcos,
>
> On Fri, 05 Mar 2010 12:33:58 +0100, Marcos Caceres <marcosc@opera.com>
> wrote:
>> General comment:
>> I'm confused as to the intended audience of this document. This
>> document is heavy on HTML5 jargon which would make it difficult for an
>> author to use without having to refer to the HTML spec itself. If this
>> document is intended for authors, then my opinion is that it needs a
>> lot of clarifications (which I've asked for below). If its intended
>> for implementers, I really don't see the point of this document.
>
> It's intended for authors. It's not intended to be the definitive
> reference, but just a quick overview of things.

Personally, I don't think the document achieves this at the moment. It 
raises more questions than it answers... though, when you answer my 
questions below *in the document*, I will be one very happy author and 
will feel that the document does meet its intention:)

>
>> I've reviewed this document with my "author" and "generally interested
>> in this stuff" hat on. I have been using HTML for 15 years now, so I
>> use that as my knowledge base. I would like to see each of the
>> questions below answered in the document (i.e, I don't care for
>> responses to questions in this email, just an acknowledgment that the
>> things have been clarified in the document - but if you want to
>> include the new text that you add as part of the response, that's ok
>> with me)...
>
> Reading your comments I think you may actually be interested in a
> difference effort:
>
> http://wiki.whatwg.org/wiki/Rationale

That "effort" is pretty thin on content, manpower, authority and 
rationale - though I'm sure the intentions are good. Also, the rationale 
seems pretty self serving. If you find something useful in the 
Rationale, then perhaps you should fold it into this authoritative W3C 
document.

>> On Fri, Mar 5, 2010 at 9:16 AM, Marcos Caceres <marcosc@opera.com> wrote:
>>> 1. Introduction
>>>
>>> HTML has been in continuous evolution since it was introduced to the
>>> Internet in the early 1990s.
>>
>> Reference to the first draft of HTML would be nice here.
>
> I don't think that's needed. If people are interested they can look it up.

Ok.

>>> Some features were introduced in
>>> specifications; others were introduced in software releases.
>>
>> Like which? and why?
>
> I don't think that's of relevance to this document.

If that was not relevant, I would not have asked.

>>> In some
>>> respects, implementations and author practices have converged with
>>> each other and with specifications and standards, but in other ways,
>>> they continue to diverge.
>>
>> The above is weak on it's own (it reads like a personal observation).
>> Can you expand on it and give concrete examples.
>
> I don't think that's of relevance to this document. It's really just an
> introduction, not a definitive reference.

As way of introduction, the above assertion basically frames the 
rationale for the document. Without concrete examples, it just sounds 
like rhetorical grandstanding.

>>> HTML4 became a W3C Recommendation in 1997. While it continues to serve
>>> as a rough guide to many of the core features of HTML, it does not
>>> provide enough information to build implementations that interoperate
>>> with each other and, more importantly, with a critical mass of
>>> deployed content.
>>
>> This may be generally accepted by some members of the community, yet
>> it does not let outsiders know what what actually wrong with the way
>> HTML4 was specified. This is really important, because it underpins
>> why HTML5 is such a large spec and why it covers so much stuff. Can
>> you please clearly list the deficiencies which HTML4 has and how HTML5
>> has attempted to overcome those (i.e., what processes are actually in
>> place to avoid the mistakes of HTML4 being remade in HTML5).
>
> I don't think that's of relevance to this document, but it would
> certainly be interesting to have such a document. The audience of such a
> document would not be authors though, I would think.

I don't see how this cannot be relevant to this document. This, in fact, 
_is_ the whole point of this document. That is at the core of the 
fundamental difference between HTML4 and HTML5. I would again request 
that the document clearly list the deficiencies which HTML4 has and how 
HTML5 has attempted to overcome those.

>>> The same goes for XHTML1, which defines an XML
>>> serialization for HTML4, and DOM Level 2 HTML, which defines
>>> JavaScript APIs for both HTML and XHTML. HTML5 will replace these
>>> documents. [DOM2HTML] [HTML4] [XHTML1]
>>
>> What does it mean that HTML5 will replace these documents? Will those
>> documents all be marked as obselete? Will an authors be discouraged
>> from using HTML < 5?
>
> Yes, though since there are still some ongoing debates I think it is
> better to leave it vague. No need to predict the future.

WFM.

>>> The HTML5 draft reflects an effort, started in 2004, to study
>>> contemporary HTML implementations and deployed content.
>>
>> Where is this study published? What methodology was used to gather the
>> results and draw conclusions? Where is the data available?
>
> To study something does not mean something was published:
>
> http://www.answers.com/study

Thanks for the link. That is true that publishing is not a requirement, 
but then how did the working group communicate its motivations for 
getting this work forward? To imply a "study" was conducted also implies 
that the results of that study were communicated to the community and 
that the community agreed that something was needed.

If you can't produce evidence of who conducted the study and how the 
results of that study were communicated to the community, then you must 
remove this section.

If it helps jog your memory, studies where done like this one: 
http://code.google.com/webstats/, which has evidently [1] underpinned 
some of decisions made by the editor of HTML5 - and shared within the 
community to sway opinion. Please reference it as at least one study.

[1] "http://code.google.com/webstats/" site:http://w3.org/

The reason it must be listed is that, as I mentioned above, people 
should be able to ascertain the historical decisions that lead to the 
creation of HTML5. People should also be able to scrutinize the 
methodology and results that was used in the study (particularly the one 
above, even if it only played a small role in the overall effort).

> But you can find data scattered throughout the web. I'm sure if you ask
> on #whatwg on Freenode people can provide you pointers.

For historical purposes of this document, that's not helpful. Those 
people and channels won't be there forever. This document will hang 
around for a long time.

>>> The draft:
>>
>> Which draft?
>
> HTML5 of course.
>
>
>>> 1. Defines a single language called HTML5 which can be written in
>>> HTML syntax and in XML syntax.
>>> 2. Defines detailed processing models to foster interoperable
>>> implementations.
>>
>> " to foster" > "that aims to foster"
>
> I don't think this is needed.

mkay.

>>> 3. Improves markup for documents.
>>
>> In what way? point 3 seems out of context with the rest of the points
>> listed here.
>
> Syntax (1), processing models (2), language for documents (3), and APIs
> for applications (4) does not seem out of context to me. They roughly
> represent the goals.

Ok, make sure that is clear in the document.

>>> 4. Introduces markup and APIs for emerging idioms, such as Web
>>> applications.
>
>
>>> 1.1. Open Issues
>>>
>>> HTML5 is still a draft. The contents of HTML5, as well as the contents
>>> of this document which depend on HTML5, are still being discussed on
>>> the HTML Working Group and WHATWG mailing lists. The open issues
>>> include (this list is not exhaustive):
>>>
>>> * De facto semantic definitions for some formerly presentational
>>> elements.
>>
>> Why is this an open issue? Either describe it, or link to something
>> that describes it.
>>
>>> * Details of accessibility and media-independence features, such
>>> as the alt and summary attributes.
>>
>> Why is this an open issue? Either describe it, or link to something
>> that describes it.
>
> It's just a summary that not all is settled yet. If authors care about
> the details they can join the HTML WG.

That's both unfair and exclusive. The cost of a few sentences on your 
part VS a person having to receive hundreds of emails a month. You know, 
not everyone is privileged to get paid to work on standardization and 
read WG emails. Please have the decency to provide appropriate 
information.

>>> 1.2. Backwards Compatible
>>>
>>> HTML5 is defined in a way that it is backwards compatible with the way
>>> user agents handle deployed content.
>>
>> How does it achieve this?
>
> I don't think that's relevant for authors. They just need to know that
> it is.

I'm an author. It's relevant to me. Please put it in.

>>> To keep the authoring language
>>> relatively simple for authors several elements and attributes are not
>>> included as outlined in the other sections of this document, such as
>>> presentational elements that are better dealt with using CSS.
>>>
>>> User agents, however, will always have to support these older elements
>>> and attributes and this is why the specification clearly separates
>>> requirements for authors and user agents.
>>
>> s/this specification/the HTML5 specification/
>
> It does not say "this".

s/the specification/the HTML5 specification/

>>> This means that authors
>>> cannot use the isindex or the plaintext element, but user agents are
>>> required to support them in a way that is compatible with how these
>>> elements need to behave for compatibility with deployed content.
>>
>> The above is just an example of various possible strange elements, right?
>
> Right.

Please make that clear if you have not done so.

>>> Since HTML5 has separate conformance requirements for authors and user
>>> agents there is no longer a need for marking features "deprecated".
>>
>> Why is that, how does that work? (Although the document is nicely
>> written, your writing consistently assumes that the reader will be
>> able to deduce why a decision was taken - when you do this, and the
>> reader (me) cannot understand why a decision was made, it makes them
>> feel stupid. Please explain "clever" decisions like the author
>> requirements... for instance, authoring requirements make no sense as
>> authors are not products that can conform to the specification. I'm
>> sure there is a very clever answer to this, so I hope to read it in
>> the next draft! )
>
> I don't follow this. How can authors not conform to requirements?

I'm asking you that exact question: How can a human being, made of flesh 
and blood (and not markup), conform to a requirement? And if they don't 
conform, why does that matter (i.e., what are the consequences, if any)?

Please answer that clearly in the document.

>>> 1.3. Development Model
>>>
>>> The HTML5 specification will not be considered finished before there
>>> are at least two complete implementations of the specification.
>>
>> What does this mean in practice? How will completeness be shown?
>
> Clarified.

"The HTML5 specification will not be considered finished before there 
are at least two complete implementations of the specification. A test 
suite will be used to measure completeness of the implementations. This 
approach differs from previous versions of HTML. The goal is to ensure 
that the specification is implementable, and usable by authors once it 
is finished."

I still don't understand what is different? HTML4 has a test suite?

http://www.w3.org/MarkUp/Test/HTML401/current/

What is it that this WG is doing differently (process-wise)? Please 
clarify and maybe point to some processes that will ensure completeness. 
E.g.: "The WG aims to produce around 20,000 tests over the next 7 years. 
Company X, Y, and Z have committed xxx number of resources to this 
monstrous task, as well as millions of dollars and a yacht on which test 
makers will be kept chained to computers until it's done, etc..."

>>> 1.4. Impact on Web Architecture
>>>
>>> The following areas / features defined in HTML5 are believed to impact
>>> the Web architecture:
>>
>> What is the "Web architecture" in this context? And what do you mean
>> by "impact"? does it change it in some fundamental way?
>
> I removed this section.

Thanks.

>>> 2. Syntax
>>>
>>> HTML5 defines an HTML syntax that is compatible with HTML4 and XHTML1
>>> documents published on the Web, but is not compatible with the more
>>> esoteric SGML features of HTML4, such as processing instructions and
>>> shorthand markup.
>>
>> Why is it not compatible?

I see "such as processing instructions and shorthand markup." Ok, that 
makes sense now.

>
>
>>> Documents using the HTML syntax are almost always
>>> served with the text/html media type.
>>>
>>> HTML5 also defines detailed parsing rules (including "error handling")
>>
>> I would drop "detailed", though the may be "detailed", that is a
>> matter of opinion.
>
> I think it reads better with it in (also an opinion, I know :-)).

:)

>>> for this syntax which are largely compatible with popular
>>> implementations.
>>
>> Please reference the implementations on which the parsing is based.
>> And please explain why those implementations (be it browser or search
>> engine) were chosen as the basis on which the parsing algorithm was
>> based on.
>
> I don't think this is of relevance to this document, but it would sure
> be interesting.

I disagree. It's common knowledge that parsing is mostly based on IE6. I 
don't see the problem with mentioning IE6 there.

If the common knowledge is wrong, then this is the document that has to 
set the record straight.

>>> User agents must use these rules for resources that
>>> have the text/html media type. Here is an example document that
>>> conforms to the HTML syntax:
>>
>> I'm not sure why this example is here? What does this have to do with
>> parsing? How is the parsing of this document any different from HTML4?
>
> It illustrates what was just explained. The DOCTYPE is different. <meta
> charset> is too.

Ok, then please add "(note the differences in <doctype> and <meta 
charset>)."

Better yet, you should have a side by side comparison of the two. You 
could make the distinction much more clear if you showed a minimally 
conforming document, like this:

<!doctype html>
<html>
<meta charset="UTF-8">
<title>Example document</title>
<p>Example paragraph

The above example totally valid/conforming (http://html5.validator.nu/) 
and really illustrates the differences - and gets rid of all those 
redundant closing tags!

>>> <!doctype html>
>>> <html>
>>> <head>
>>> <meta charset="UTF-8">
>>> <title>Example document</title>
>>> </head>
>>> <body>
>>> <p>Example paragraph</p>
>>> </body>
>>> </html>
>>>
>>> HTML5 also defines a text/html-sandboxed media type for documents
>>> using the HTML syntax. This can be used when hosting untrusted
>>> content.
>>
>> Be nice to say that HTML < 5 did not have this. What's untrusted
>> content? Can you go into some details about the usage or reason why
>> this is useful (e.g., how it affects scripting capabilities)?
>
> This document is not intended for such depth.

Ok, at least make sure you link to the relevant section in HTML5.

>>> The other syntax that can be used for HTML5 is XML. This syntax is
>>> compatible with XHTML1 documents and implementations. Documents using
>>> this syntax need to be served with an XML media type
>>
>> You should reference the XML or XHTML media type spec. Or link to it.
>
> HTML5 defines the XHTML media type and is referenced.
>
>
>>> and elements need
>>> to be put in the http://www.w3.org/1999/xhtml namespace following the
>>> rules set forth by the XML specifications. [XML]
>>
>> This seems redundant, given that it's all part of xhtml.
>
> But usually it's not immediately clear in my experience.

Clearly not. I'm more confused now. Why is this not all defined in one 
place :(

Anyway, I'm all for leaving it ambiguous as getting into namespace land 
always leads to confusion.

>>> authors have three means of setting the
>>> character encoding:
>>>
>>> * At the transport level. By using the HTTP Content-Type header
>>> for instance.
>>> * Using a Unicode Byte Order Mark (BOM) character at the start of
>>> the file. This character provides a signature for the encoding used.
>>> * Using a meta element with a charset attribute that specifies the
>>> encoding within the first 512 bytes of the document. E.g. <meta
>>> charset="UTF-8"> could be used to specify the UTF-8 encoding. This
>>> replaces the need for <meta http-equiv="Content-Type"
>>> content="text/html; charset=UTF-8"> although that syntax is still
>>> allowed.
>>
>> How is this different from HTML4?
>
> <meta charset> was not in HTML4.

Ok, please make sure that is clear. AS in "What is different in HTML5 is 
the addition of the charset attribute to the meta element." or something.

>>> For the XML syntax, authors have to use the rules as set forth in the
>>> XML specifications to set the character encoding.
>>
>> How is this any different from XHTML?
>
> It isn't.
>
>
>> Seem that this whole section is explaining features, not differences.
>
> It seemed appropriate to have a section on syntax.

WFM.

>>> 2.2. The DOCTYPE
>>>
>>> The HTML syntax of HTML5 requires a DOCTYPE to be specified to ensure
>>> that the browser renders the page in standards mode.
>>
>> What is this "standards mode"?
>
> Most authors reading this document will already be familiar with the term.

Half the time you seem to assume authors knows little, then the other 
time you assume they know a lot. I recommend you print out a picture of 
me, and put it next to you when writing. Then you can ask, "would Marcos 
know this?... probably not"... or "Will Marcos ask me stupid questions 
about this?... probably."

>>> The DOCTYPE has
>>> no other purpose and is therefore optional for XML. Documents with an
>>> XML media type are always handled in standards mode. [DOCTYPE]
>>>
>>> The DOCTYPE declaration is <!DOCTYPE html> and is case-insensitive in
>>> the HTML syntax. DOCTYPEs from earlier versions of HTML were longer
>>> because the HTML language was SGML-based and therefore required a
>>> reference to a DTD.
>>
>> What did this longer DOCTYPE look like, so we can see the differences
>> from HTML4?
>
> It is assumed you already know HTML4.

That is a fair assumption to make. It's nice to show it because it 
drives the point home: As in, "OMG! look how complex and stupid that 
thing that did nothing was!".

>>> With HTML5 this is no longer the case and the see
>>> DOCTYPE is only needed to enable standards mode for documents written
>>> using the HTML syntax. Browsers already do this for <!DOCTYPE html>.
>>
>> So, basically, it's required to identify a document as HTML5? This is
>> unclear because the whole standards mode thing is undefined. You need
>> to expand this section to show how it actually works and explain that
>> an old doc type will still trigger HTML5 features if available
>> (presumably).
>
> Since that is non-conforming I don't think it's relevant for authors.

Well, for authors who have had years of indoctrination about <!DOCTYPE> 
it is. Bottom line is, that the doctype doesn't enable features. And, 
not even case matters when it comes to the doctype. It is important to 
make it clear that <!DocType> is <!DOCtype> is <!docTYPE> and people 
need to stop being religious about it (which is what HTML5 finally 
codifies).

>>> 2.3. MathML and SVG
>>
>> You should start with "Unlike HTML4," or something...
>
> Why, it already says "of HTML5".

It's a "differences" document: it gives rationale as to why the 
paragraph is there.


>>> 2.4. Miscellaneous
>>>
>>> There are a few other syntax changes worthy of mentioning:
>>> * The lang attribute takes the empty string in addition to a valid
>>> language identifier, just like xml:lang does in XML.
>>
>> So what? What does that mean in terms of difference with HTML4 in
>> terms of behavior?
>
> That you can do more? I don't get your comment.

My bad here. I get what you are saying now.

>>> 3. Language
>>>
>>> This section is split up in several subsections to more clearly
>>> illustrate the various differences there are between HTML4 and HTML5.
>>> 3.1. New Elements
>>>
>>> The links in this section may stop working if elements are renamed
>>> and/or removed. They should function in the latest version of this
>>> draft.
>>>
>>> The following elements have been introduced for better structure:
>>>
>>> *
>>>
>>> section represents a generic document or application section. It
>>> can be used together with the h1, h2, h3, h4, h5, and h6 elements to
>>> indicate the document structure.
>>
>> On what grounds was the addition of the section element made? what was
>> lacking in HTML4?
>
> That seems like something for this document:
>
> http://wiki.whatwg.org/wiki/Rationale

To me, it seems like something that should be in this document. Also, 
I'm not interested in the WHATWG HTML spec, I am interested in the W3C 
HTML spec. It's already terribly confusing that there are two versions, 
and the fact that the WHATWG version keeps growing outside the scope of 
the W3C version might make the scope of the WHATWG rationale larger than 
W3C HTML5.

> Since you are asking the same question for all new elements I have
> omitted those questions from my reply.

For each, the questions still apply.

>>> mark represents a run of marked text.
>>
>> What's "marked text"?
>
> Clarified.

Is the clarification the link? (if so, I'm ok with that).

>> <snip/>
>>
>>> 3.2. New Attributes
>>>
>>> HTML5 has introduced several new attributes to various elements that
>>> were already part of HTML4:
>>>
>>> *
>>>
>>> The a and area elements now have a media attribute for
>>> consistency with the link element. It is purely advisory.
>>
>> What does "purely advisory" mean?
>
> Elided.

mkay.

>
>>> *
>>>
>>> The a and area elements have a new attribute called ping that
>>> specifies a space-separated list of URLs which have to be pinged when
>>> the hyperlink is followed. Currently user tracking is mostly done
>>> through redirects. This attribute allows the user agent to inform
>>> users which URLs are going to be pinged as well as giving
>>> privacy-conscious users a way to turn it off.
>>> *
>>>
>>> The area element, for consistency with the a and link elements,
>>> now also has the hreflang and rel attributes.
>>
>> What does it do?
>
> See HTML4 (well, or HTML5 if you're not familiar with HTML4).

Put the above into the doc. Or at least link to the attributes... though 
I still don't know what they do :(

>>> *
>>>
>>> The base element can now have a target attribute as well, mainly
>>> for consistency with the a element. (This is already widely
>>> supported.)
>>
>> s/a element. (T/a element (t
>>
>> And put the stop outside the ")".
>
> Really? It is a separate sentence.

Matter of style, I guess.

>>> The meta element has a charset attribute now as this was already
>>> widely supported and provides a nice way to specify the character
>>> encoding for the document.
>>
>> nice way? you mean more compact?
>
> I don't think changing this would improve the quality of the document.

I wouldn't mention if it did not draw attention to itself. Otherwise, 
retitle the document "Things Anne Thinks are Nicer in HTML5 over 
HTML4"...

>
>>> *
>>>
>>> A new placeholder attribute can be specified on the input and
>>> textarea elements.
>>> *
>>
>> What does it do?
>
> Clarified.

It still says the same thing "A new placeholder attribute can be 
specified on the input and textarea elements."?


>
>
>>> The new form attribute for input, output, select, textarea,
>>> button and fieldset elements allows for controls to be associated with
>>> a form. I.e. these elements can now be placed anywhere on a page, not
>>> just as descendants of the form element.
>>
>> The above is confusing - I had to read it a few times to get it. Maybe
>> include an example.
>
> Done.

Cool, better.


>>> *
>>>
>>> The new required attribute applies to input (except when the
>>> type attribute is hidden, image or some button type such as submit)
>>> and textarea. It indicates that the user has to fill in a value in
>>> order to submit the form.
>>
>> What's the purpose? Does it block the user from submitting?
>
> There are too much scenarios here to explain that concisely. It already
> explains its general purpose, if people want to use it they can easily
> find out more.

ok.

>>> *
>>>
>>> The fieldset element now allows the disabled attribute disabling
>>> all its contents when specified.
>>
>> What does it mean "disabling all its content"? Maybe this should say
>> something about being able to interface with the element?
>
> I think it is fine as is.

Maybe say "disabling all form elements it contains" (assuming that is 
what it means)?

>>> *
>>>
>>> The input element has several new attributes to specify
>>> constraints: autocomplete, min, max, multiple, pattern and step. As
>>> mentioned before it also has a new list attribute which can be used
>>> together with the datalist element.
>>
>> Why were these added?
>
> That is something for this document to answer:
>
> http://wiki.whatwg.org/wiki/Rationale

I think it should be answered in this document for the reasons I have 
given above.

>>> *
>>>
>>> The form element has a novalidate attribute that can be used to
>>> disable form validation submission (i.e. the form can always be
>>> submitted).
>>
>> What does this do? is this a script thing?
>
> See my comment on the required attribute.

Ok, but I still don't get this one: Is this something you would use for 
testing? Or is to to override a form with novalidate within another 
form?

>>> *
>>>
>>> The input and button elements have formaction, formenctype,
>>> formmethod, formnovalidate, and formtarget as new attributes. If
>>> present, they override the action, enctype, method, novalidate, and
>>> target attributes on the form element.
>>
>> Why is this significant?
>
> It is a difference from HTML4.

Fair enough. Again, it would be nice to know what motivated these 
additions. However, a, simple "see the specification for a rationale" or 
some link to the use cases for this new stuff... All the form stuff is 
really interesting.

>>> *
>>>
>>> The menu element has two new attributes: type and label. They
>>> allow the element to transform into a menu as found in typical user
>>> interfaces as well as providing for context menus in conjunction with
>>> the global contextmenu attribute.
>>
>> Why is this significant? You should probably talk a little about the
>> contextmenu attribute, as you have not yet discussed it in the
>> document. At least say you talk about it later.
>
> If people are interested in this feature they will find out more about
> it. This document is just a summary.

It seems to be just a summary in parts, and in other parts it goes into 
detail. Having hit other good summaries in the document, it follows that 
summaries will be given throughout.

>>> *
>>>
>>> The style element has a new scoped attribute which can be used
>>> to enable scoped style sheets. Style rules within such a style element
>>> only apply to the local tree.
>>
>> What's a "scoped style sheet"?
>
> That is explained in the next sentence.

Ok.

>>> *
>>>
>>> The script element has a new attribute called async that
>>> influences script loading and execution.
>>
>> How does it influence it? what for?
>
> Again, this document is just summary.


as above.

>>> *
>>>
>>> The html element has a new attribute called manifest that points
>>> to an application cache manifest used in conjunction with the API for
>>> offline Web applications.
>>
>> What's an "application cache manifest"?
>
> See above.

heh, recursive see above :)

>>> *
>>>
>>> The link element has a new attribute called sizes. It can be
>>> used in conjunction with the icon relationship (set through the rel
>>> attribute) to indicate the size of the referenced icon.
>>
>> What? icons in HTML? what's are these "icons"?
>
> Favicons have been age-old.

Maybe you should say that this is for explicitly setting the fav icon? 
Or is there some other use case?

>>> *
>>>
>>> The ol element has a new attribute called reversed to indicate
>>> that the list order is descending when present.
>>
>> s/present/presented ?
>
> No.

Ah, get it - your sentence has 3 ideas in it. That sentence should be:

"The ol element has a new attribute called reversed. When present, it 
indicates that the list order is descending."

Please change it to avoid confusion and for legibility.

>
>>> *
>>>
>>> The iframe element has three new attributes called sandbox,
>>> seamless, and srcdoc which allow for sandboxing content, e.g. blog
>>> comments.
>>
>> What does this do?
>
> It's just a summary.

Ok, please link to their definitions then in HTML5.


>>> such as the play event which is
>>> used by the API for the media elements, video and audio.
>>> 3.3. Changed Elements
>>>
>>> These elements have slightly modified meanings in HTML5 to better
>>> reflect how they are used on the Web or to make them more useful:
>>>
>>> *
>>>
>>> The a element without an href attribute now represents a
>>> "placeholder link". It can also contain flow content rather than being
>>> restricted to phrase content.
>>
>> What's a "placeholder link"? What's flow content?
>
> I think if people are interested in this they can find out more easily
> enough. Not sure if an explanation would really help as it would only be
> relevant here.

I hold that placeholder link is ambiguous, I would like a brief 
explanation - I had to look that one up, actually. I call that an anchor 
(or an a href element with an id attribute). You could just say that.

>>> *
>>>
>>> The address element is now scoped by the new concept of sectioning.
>>
>> scoped? What does that mean?
>>
>> What was it before (in HTML4)?
>
> Not scoped. Details are in HTML5.

Please define or link to it.

>>> *
>>>
>>> The b element now represents a span of text to be stylistically
>>> offset from the normal prose without conveying any extra importance,
>>> such as keywords in a document abstract, product names in a review, or
>>> other spans of text whose typical typographic presentation is
>>> emboldened.
>>> *
>>>
>>> The hr element now represents a paragraph-level thematic break.
>>
>> "paragraph-level thematic break"? What's that? Is that a restriction?
>> Can't I user it wherever I want?
>>
>> What was it before (in HTML4)?
>
> Authors are assumed to know what it was before. I elided all similar
> questions.

Isn't there some non-fancy way of saying "paragraph-level thematic 
break"? I still don't know what it is:(


>>> *
>>>
>>> The summary attribute on table. The HTML5 draft defines several
>>> alternative solutions.
>>
>> Solutions to what? Please list them.
>
> It already states they are in HTML5.

ah, I get it. Please link to them. HTML5 is an 800 page monster spec and 
searching it can be painful (like it freezes every browser and takes 
ages to load!).

>>> 3.5. Absent Elements
>>>
>>> The elements in this section are not to be used by authors. User
>>> agents will still have to support them and various sections in HTML5
>>> define how. E.g. the obsolete isindex element is handled by the parser
>>> section.
>>>
>>> The following elements are not in HTML5 because their effect is purely
>>> presentational and their function is better handled by CSS:
>>
>> (It's nice when you give clear rationale for decisions :) More like
>> the above would make this doc really useful )
>
> You're not interested in what "purely presentational" means? ;-)

It's pretty clear: of being only presented by visual means and holding 
not of limited semantic value. What else could it possibly mean? :)

>> <snip>
>>
>>>
>>> The following elements are not in HTML5 because their usage affected
>>> usability and accessibility for the end user in a negative way:
>>
>> In what negative way?
>
> http://wiki.whatwg.org/wiki/Rationale

Doesn't help. If you insist on referencing the WHATWG wiki, then make it 
a formal reference in this spec. Please don't answer questions for my 
benifit, but for the benefit of all readers.

>>> * frame
>>> * frameset
>>> * noframes

You lied! These are not listed in http://wiki.whatwg.org/wiki/Rationale 
!:) Please define this here.

>> So what happens to these guys in a HTML5 UA?
>
> Not relevant to authors.

How is that not relevant? I might still want to use <frame> for stuff? 
It will still work right?

>>> 3.6. Absent Attributes
>>>
>>> Some attributes from HTML4 are no longer allowed in HTML5. If they
>>> need to have any impact on user agents for compatibility reasons it is
>>> defined how they should work in those scenarios.
>>
>> Defined where? (e.g., as part of the parsing model?)
>
> Doesn't matter to authors.

I'm an author. It matters to me. Therefore, it matters to authors.

Also, how are you, or the WG, deciding what matters to authors and what 
doesn't?

>>> * rev and charset attributes on link and a.
>>> * shape and coords attributes on a.
>>> * longdesc attribute on img and iframe.
>>> * target attribute on link.
>>> * nohref attribute on area.
>>> * profile attribute on head.
>>> * version attribute on html.
>>> * name attribute on img (use id instead).
>>> * scheme attribute on meta.
>>> * archive, classid, codebase, codetype, declare and standby
>>> attributes on object.
>>> * valuetype and type attributes on param.
>>> * axis and abbr attributes on td and th.
>>> * scope attribute on td.
>>
>> Why were all these dropped? I would like to know the rationale for
>> each one.
>
> http://wiki.whatwg.org/wiki/Rationale

Not helpful. It does not cover these. Please explain.

Also, there is no process for that Wiki. There is no heartbeat 
requirement, or any one from any company assigned to edit it (I can see 
from the history that Simon has edited it from time to time, but that's 
not good enough. It has no committed editor and Opera's position is that 
authoritative information should be coming from the W3C, not the WHATWG.)

>> <snip>
>>
>>> 4. APIs
>>>
>>> HTML5 introduces a number of APIs that help in creating Web
>>> applications. These can be used together with the new elements
>>> introduced for applications:
>>>
>>> * API for playing of video and audio which can be used with the
>>> new video and audio elements.
>>
>> Be nice to link to it, or at least say what the interface is?
>>
>>> * An API that enables offline Web applications.
>>
>> Be nice to link to it, or at least say what the interface is?
>>
>>> * An API that allows a Web application to register itself for
>>> certain protocols or media types.
>>
>> Be nice to link to it, or at least say what the interface is?
>>
>>> * Editing API in combination with a new global contenteditable
>>> attribute.
>>
>> Be nice to link to it, or at least say what the interface is?
>>
>>> * Drag & drop API in combination with a draggable attribute.
>>
>> Be nice to link to it, or at least say what the interface is?
>>
>>> * API that exposes the history and allows pages to add to it to
>>> prevent breaking the back button.
>>
>> Be nice to link to it, or at least say what the interface is?
>
> I think these are all trivial enough to find within the HTML5
> specification if you're interested. Or you can find them in blog posts,
> journals, etc.

Blog posts, journals, etc. get stuff wrong - all the time! W3C Schools, 
A List Apart, Wikipedia, anyone?:) Or do you want a repeat of XHTML?!

So yeah, you better link to correct sections of the the spec for each of 
the above :)

>>> 4.1. Extensions to HTMLDocument
>>>
>>> getSelection() which returns an object that represents the
>>> current selection(s).
>>
>> Just text? or markup too?
>
> Ranges iirc.

Ok, please make that clear in the doc.

>>> 4.2. Extensions to HTMLElement
>>> getElementsByClassName() which is basically a scoped version of
>>> the one found on HTMLDocument.
>>
>> What does it mean, "a scoped version"?
>
> What is unclear about scoped?

On second reading, it's ok. There is a lot jargon (admittedly, most of 
it necessary) in the document, so sometimes I confuse pronouns with jargon.

>>> manipulating the element's classes. The a, area and link elements have
>>> a similar attribute called relList that provides the same
>>> functionality for the rel attribute.
>>
>> What is that used for?

It reads "The object it returns, exposes methods"

The comma is strange there. But otherwise, it makes sense.

-- 
Marcos Caceres
Opera Software

Received on Thursday, 10 June 2010 08:31:20 UTC