On Thu, 10 Jun 2010 10:30:46 +0200, Marcos Caceres <[email protected]>
wrote:
On 6/8/10 2:53 PM, Anne van Kesteren wrote:
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:)
Raising questions is fine. It gives people a reason to explore things
further. If a quick overview of things did not raise questions, frankly,
I'd be surprised.
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.
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 :-)
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.
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.
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.
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.
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?
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.
Ok, I removed the issues and mentioned that they are linked from the HTML5
draft.
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?
s/this specification/the HTML5 specification/
It does not say "this".
s/the specification/the HTML5 specification/
Because you asked so nicely.
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.
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.
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?
Fair enough. Clarified some more.
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..."
I hope what I did is ok. I'm not too interested in making it too complex
and trying to predict the future and all.
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.
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?
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 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.
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.
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.
It already says it replaces the need for the older syntax. I think it is
fine.
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.
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 :-)
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.
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.
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.
I think "of HTML5" does that.
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.
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.
Grand.
mark represents a run of marked text.
What's "marked text"?
Clarified.
Is the clarification the link? (if so, I'm ok with that).
No. You might seen it does not say "marked text" anymore?
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.
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.
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?
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.
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.
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?
You could have [Save Draft] and [Submit]. [Save Draft] might carry a
novalidate attribute.
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.
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.
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?
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.
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.
Boring, done.
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.
See the bit on links I wrote earlier.
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.
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.
See the bit on links I wrote earlier.
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:(
Did you look at HTML5?
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!).
See the bit on links I wrote earlier.
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.
* 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!
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.
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.
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.
* 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.)
I already explained I do not consider it to be in scope of this document.
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.
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?
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.
It reads "The object it returns, exposes methods"
The comma is strange there. But otherwise, it makes sense.
You remember you wrote the following last time, right?
# typo: returns exposes?
--
Anne van Kesteren
http://annevankesteren.nl/
