RE: review of HTML5 differences from HTML4

> I seek the working group's position on a number of issues below. 

Since the referenced dialogue on the public-html-comments@w3.org list has not worked for you, then the WG Chairs recommend that you open Bugzilla bugs against the "HTML5 differences from HTML4" component of the HTML WG's Bugzilla component:
http://www.w3.org/Bugs/Public/enter_bug.cgi


a) Choose the HTML WG component or go to http://www.w3.org/Bugs/Public/enter_bug.cgi?product=HTML%20WG 
b) Set the Component to the "HTML5 diffs from HTML4"
c) Enter one problem in each Bugzilla bug 

The Editor will respond to your bug(s) and if you disagree with the disposition of your bug(s) then you can escalate the item(s) to WG Issues as described in the WG Decision Policy [1].  This is the best way to clearly "seek the working group's position" on your issues.

Please let the Chairs know if you have any questions about this response.

/paulc
For the HTML WG Chairs

[1] http://dev.w3.org/html5/decision-policy/decision-policy.html 

Paul Cotton, Microsoft Canada
17 Eleanor Drive, Ottawa, Ontario K2E 6A3
Tel: (425) 705-9596 Fax: (425) 936-7329


-----Original Message-----
From: public-html-comments-request@w3.org [mailto:public-html-comments-request@w3.org] On Behalf Of Marcos Caceres
Sent: Monday, June 28, 2010 6:44 AM
To: Anne van Kesteren; Sam Ruby
Cc: public-html-comments@w3.org
Subject: Re: review of HTML5 differences from HTML4

Dear HTML-WG Chair,
Parts of the discussion in the email below have resulted in deadlocks 
between myself and the editor of the "HTML5 differences from HTML4" 
document. The points of contention are around what appear to be personal 
positions taken by the editor, rather than position that represent the 
HTML WG. I seek the working group's position on a number of issues 
below. If the editor is said to speak on behalf of the working group, 
then all my objections are mute.

Dear Anne,
Thank you again for the time and effort in answering my questions. 
Comment below...

On 6/23/10 10:18 AM, Anne van Kesteren wrote:
>>> 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.
>
> a) You can help out, it's a wiki! b) Rationale should probably be a
> separate document. It is rather different from this document.

Look, even in the abstract of your document it says "provides some of 
the rationale for the changes."

That Wiki has no official standing and it's not part of any legally 
recognized organization or consortium. I'm not going to go and add stuff 
to some random Wiki when there is a perfectly good document, which you 
are editing, from a reputable and internationally recognized 
institution: the W3C.

If the WHATWG was to incorporate or become a real consortium or 
non-profit organization, then I'd be happy to submit my input there. 
However, until that time, the WHATWG has little credibility and I will 
continue to submit my comments here.

Again, please provide the rationale for the differences between HTML4 
and HTML5 in this document.
 
>>>>> 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.
>
> Nice retort, but you are not to decide what is relevant :-)

Fine, then you leave me no option but to request a working group 
decision on this matter and/or a formal response from the WG chair.

>>>>> 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.
>
> It just illustrates things are complex.

It fails to illustrate that: it reads like rhetorical grandstanding. To 
illustrate that things were complex, your would need some concrete 
examples or data.

>>>>> 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.
>
> It is not at all the whole point of this document. The point is to point
> out what is new and has changed compared to HTML4, because authors know
> HTML4. Explaining how HTML4 was completely inadequate is interesting
> research and might be of use to people writing specifications, but for
> everyone else it is moot as we have HTML5 now.

I respectfully disagree. I call on the WG to make a formal decision 
about this matter. I would also add that writers of specification are 
also authors of HTML, such as you and I.

>>>>> 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).
>
> It is a single sentence explaining something. Of course I know about
> /webstats/ and the tens (if not hundreds) of issues I reported with
> HTML5 over the course of five years with respect to it matching or not
> matching contemporary implementations. But this is a single sentence and
> making more out of it is not worth it. The /webstats/ document will be
> around for a long time, W3C Bugzilla will be around as long as the /TR/
> pages most likely, and the HTML and WHATWG mailing list archives
> probably too. Tons of research can be done on our research.

The paragraph above is exactly what I what I want to see in the document :)

>>> 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.
>
> See above.

Then link to 'em. History will thank you.

>>>>> 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.
>
> What exactly would you like me to change?

I would like you to describe in what way HTML5 "*Improves* markup for 
documents". So, you could say, "Improves markup for documents by 
specifying a new syntax, a processing model, language for documents, and 
APIs for applications, all of which were missing from HTML4".

Also, I'm a little bit confused... and this might be a point of 
contention... is this differences document about the difference between 
the HTML specifications or the *concept* of HTML4.01 vs HTML5?


>>>>> 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.
>
> How is the next paragraph not a good enough example for this actually?

Lets see...

"User agents, however, will always have to support these older elements 
and attributes and this is why the HTML5 specification clearly separates 
requirements for authors and user agents. For instance, 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."

Ok, yes. That makes sense.

>>>>> 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.
>
> Okay.

Ok, this is making more sense now... maybe just took a couple of readings.

>>> 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.
>
> I don't want to explain what it means for a human being to follow a
> rule. That seems inane.

It's not inane, it confuses people enough to file bugs about it:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=7034


However, the sentence you have there certainly helps underscore the 
rationale for authoring requirements and backwards compat: "Since HTML5 
has separate conformance requirements for authors and user agents there 
is no longer a need for marking features "deprecated"".

I respectfully disagree that you can make authors conform as a cheap 
means of deprecating things, but I can live with the rationale.


>>>>> 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.
>
> As I explained before this document is not about explaining how HTML5
> design decisions were arrived at.

I'm asking you to make a statement of fact, not to explain how the fact 
was derived. so you could say "this syntax which are largely compatible 
with popular implementations because it is largely based on Internet 
Explorer 6's behavior."

It's important to document history here: without it, we are bound to 
make the same mistakes again. If other implementation played a role 
(e.g., the way Google's spiders process pages), then those should be 
documented too.

> For this particular piece of information maybe you should have a look at
> the acknowledgments section of HTML5. Why do you think that is common
> knowledge by the way?

Because I know about it and I'm not involved in the working group.
If it's not common knowledge, then it should be (as it explains much 
about the differences between HTML4 and 5).

>>>>> 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!
>
> HTML4 allowed that too so you have the same amount of differences.

I tried the above in both validator.nu and validator.w3.org and both 
reported it to be invalid HTML4.1 (all flavors of it).

> I
> don't think detailed comparison of these differences is interesting.
> This is enough for authors to just copy and paste and that is probably
> the most useful bit of that section.

I disagree. I think it is particularly interesting because it 
demonstrates the disconnect between markup and DOM, which is an inherent 
difference between the two languages (i.e., HTML5 is defined in terms of 
the DOM and without understanding the DOM construction algorithm, you 
are quickly gonna get into problems... while, HTML4 seems to be DOM 
agnostic or something. Anyway, important difference - be nice to see it 
in the document.).

>>> This document is not intended for such depth.
>>
>> Ok, at least make sure you link to the relevant section in HTML5.
>
> I'm only doing that for the elements at the moment. Maybe once we go to
> CR or something stable like that I could add a bunch more links.

Ok, can you add a note to the spec stating that... so you won't forget:)

>>>>> 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.
>
> Maybe, or maybe you have a knowledge gap somewhere. Hard to tell. This
> is the first time someone told me this though.

If there is a link to something that describes it, then that would 
resolve this. All those modes are very complicated.... the "almost 
standards", etc.

>> 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 typical author that works with HTML on a day-to-day basis is the
> more interesting case I think. You might be glad to know your picture is
> on my dartboard, though, albeit somewhat punctured ;-P
>
>
>>>> 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!".
>
> I'll leave that to advocacy :-)

If you want something done right, you gotta do it yourself... :)

>>>>> 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.
>
> Yes it does.

I honestly did not know that. Please explain in the doc what new 
features are enabled. This I'm actually looking forward to reading.

>> 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).
>
> This is a completely different point from your first. Authors will just
> copy a DOCTYPE and be happy. No need to confuse anyone with
> case-insensitivity.

You seem to assume a lot of things about authors (which includes you and 
I), which are a little condescending. The doctype is no longer complex, 
so it's not likely people will copy paste it anymore.

>>>> 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.
>
> Lets cross that bridge when it becomes an actual problem.

It's a problem. I would like a working group decision then on this 
matter and/or a formal response from the WG chair.

>>> 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.
>

Again, I would like a working group decision on this matter and/or a 
formal response from the WG chair.

>>>>> 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 :(
>
> If you don't know HTML4 you should read HTML4 first. (Though really
> starting with HTML5 in that case might be easier.)
>
> I might add links later when everything is stable and the moon looks funny.

A critria for making fixes when "the moon looks funny" does not seem 
acceptable to me.

>>>>> 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"...
>
> I'll consider that.

heh, that would be cool. But seriously, if this document does not 
represent the consensus of the working group then you should really 
change your attribution from "editor" to "author". That way, it is more 
clear that this is your opinion (and maybe add something to the SoTD to 
also clarify). However, if you call your self and editor, then it is 
implied that you have compiled the collective thoughts of the working 
group. The SoDT does state, after all, that this is a "W3C Working Draft 
produced by the HTML Working Group". It is assumed that what is in the 
document represents the position of the working group.

Again, I would like a working group decision on this matter and/or a 
formal response from the WG chair.

>>>>> 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."?
>
> What about the next sentence?

Ah. Ok, you need a ":" instead of a "." between the two sentences. 
Otherwise it's not clear that the next sentence explains the first.

>>>>> 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)?
>
> Clarified.

Here also you need a ":" instead of a "." between the two sentences.

Generally speaking, you should really avoid the word "it" where 
possible. It is confusing when you have sentences with more then one 
thing that "it" can apply to.

>>>>> 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.
>
> I think it should not. For reasons placed at a similar location.

I would like a working group decision then on this matter and/or a 
formal response from the WG chair.

>>>>> 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.
>
> See other rationale discussions.

I would like a working group decision then on this matter and/or a 
formal response from the WG chair.

>>>>> 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.
>
> Apparently not.

I'm not sure if you intend to fix this or not? I take it in good faith 
that you are.

>>>>> 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.

I'm confused. This is a fav icon then? Or this is something different, 
like when I bookmark a page on the iphone an it appears on my iphone's 
home screen? Please clarify in the document.

>> Maybe you should say that this is for explicitly setting the fav icon?
>> Or is there some other use case?
>
> I clarified that sizes allows for icons of distinct resolutions. It
> seems inappropriate to expand on the use cases of the icon rel
> relationship here.

Ok, I can live with that if there is a place where I can find the use 
case. If there is, please link to it.

>>>> 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.
>
> But that would be wrong. Changed the text to match what HTML5 says.

I'm really sorry, I'm really not understanding:

"The a element without an href attribute now represents a placeholder 
for where a link otherwise might have been placed."

I've read this like 5 times, then I copied it here... then I looked at 
it some more... and I don't get it. What does this actually mean in 
practice? Just put a simple example.

Also, "It can also contain flow content rather than being restricted to 
phrase content."

I don't get this. Provide a simple example. As in "before you couldn't 
do X, but now you can do Y". Please also change "it" to "The a element".

>>>>> 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:(
>
> Did you look at HTML5?

Did you link to the relevant section of HTML5 so I would know where to 
look?

Also, I'm reviewing this document with the assumption of knowing HTML4 
as an author.
I  should not have to go and look at HTML5 to get the meaning, that 
defeats the purpose of this document.


>>>>> 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.
>
> I added a reference in the changelogs section.

This does not legitimize the rationale document held by the WHATWG.

I strongly object to deferring the rationale to the WHATWG blog or 
rationale page.

>>>>> * frame
>>>>> * frameset
>>>>> * noframes
>>
>> You lied! These are not listed in
>> http://wiki.whatwg.org/wiki/Rationale !:) Please define this here.
>
> It's a wiki. Fix it!

See my initial comments on the standing of that wiki.

>>>> 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?
>
> Not relevant as long as it is not allowed. At least not to this document.

There are millions of legacy sites that use frames, which may end up 
being treated as HTML5. To simply say that they are not allowed does not 
help. What happens to frames in HTML5 and in a UA? Please explain the 
difference.

>>>>> 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.
>
> That's some weird logic.

I would like a working group decision then on this matter and/or a 
formal response from the WG chair.

>> Also, how are you, or the WG, deciding what matters to authors and
>> what doesn't?
>
> There is no point in telling authors about invalid features as the idea
> is that they are not to use them.

These are differences between the the two, hence must be explained. 
Obscuring why something has become invalid is unhelpful and deceptive. 
You can't just say it's invalid and then just expect people to behave 
like sheep and follow: you need to tell them (me) why.

> I already explained I do not consider it to be in scope of this
> document.

I sympathize with you, but the editor represents the interest of the WG. 
Hence, I would like a working group decision then on this matter and/or 
a formal response from the WG chair.

> I pointed you to an effort that attempts to address some of
> these questions. If that does not please you maybe you should step up
> and do some work, because you are certainly not making me enthusiastic.

I'm happy to find time to co-edit the document, if that is what you need 
me to do.

>>>> 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?!
>
> Why do you pretend that is all what I said while you clearly quote that
> you can find it in HTML5 as well?

Sorry, I don't understand the above. In any case, please site the 
authoritative sources.

>> So yeah, you better link to correct sections of the the spec for each
>> of the above :)
>
> See the bit about links I wrote earlier.
>
>
>>>>> 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.
>
> I do not think that will help.

I think it will. Please make that clear in the document.

-- 
Marcos Caceres
Opera Software

Received on Monday, 28 June 2010 21:32:55 UTC