<br><br><div class="gmail_quote">2008/12/25 Ian Hickson <span dir="ltr"><ian@hixie.ch></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
We're very constrained by the legacy for text/html's syntax; sadly,<br>
usability concerns aren't really able to make us change the language.<br>
<br>
[...]<br>
<br>
The goal is not to guess what the author meant when the authors makes a<br>
mistake; the goal is to have interoperable, predictable, defined behavior<br>
for all input.<br>
<br>
[...] </blockquote><div><br>See below <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
Could you elaborate on how spec design like XHTML modularisation has any<br>
impact on developers of Web applications? I was under the impression that<br>
the only benefit was in the development of other specs based on the<br>
modules (and that only if those needs happened to mesh with the particular<br>
modules picked).<br>
</blockquote><div><br>Because of XHTML Modularization, I can build a XML Schema of different markup languages, integrate and validate them, without overlapping or redundance. Yes, DTDs are not dead, just they're not used in browsers.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I assume you mean in forms?<br>
<br>
> 1) use XMLSchema datatypes<br>
<br>
It's unclear how XML Schema datatypes would work with HTML forms and how<br>
they would be better than what we have in forms in HTML5 now.</blockquote><div><br>XForms use XMLSchema datatypes (default or user-defined). Btw, I meant the first part of HTML5 spec (parsing of date - time - numbers - etc.)<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
> 2) additional DOM interfaces, which include HTMLElement - HTMLCollection -<br>
> HTMLFormsControlCollection - HTMLOptionsCollection - DOMTokenList -<br>
> DOMStringMap<br>
><br>
> 2) you don't need HTMLElement: markup insertion, attributes querying can<br>
> be done using DOM3Core (that in latest browser are even more performant<br>
> as no parser is involved), events are far better handled by DOM3Events,<br>
> styling is included by CSSOM<br>
><br>
> you don't need collection either: just use appropriate DOMNodeLists,<br>
> while for DOMStringMap you may use binding specific features (all Object<br>
> are hash maps in ECMAScript3): it works this way even in HTML5<br>
<br>
Both HTMLElement and collections are in DOM2 HTML (even DOM1 HTML).<br>
<br>
DOMStringMap is basically nothing but a binding-specific feature.</blockquote><div><br>I don't see your point<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
XHTML2 is not backwards compatible, and was a big part of the motivation<br>
behind starting the HTML5 effort.<br>
</blockquote><div><br>Still, see below. <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Extensibility is an anti-feature -- we specifically don't _want_ people to<br>
extend HTML without working with the wider community. That way lies<br>
fragmentation of the language and lack of interoperability. Indeed, what<br>
little non-centralised extension HTML has seen -- <spacer>, <blink>,<br>
<marquee> -- has been widely decried as a disaster.</blockquote><div><br>XMLHttpRequest was invented by Netscape, now it is a W3C Technical Report (I don't remember what maturity level). The same with so called DOM level 0 (now HTML5)<br>
Extensibility doesn't mean proprietary extensions: it means that organizations other than WHATWG can collaborate and you are sure that they're extension don't break existing specifications. Also this affects new versions of current module: for sure XForms 1.1 or XMLEvents 2, when they'll be finished, won't break XHTML Structural or Embedded Attributes Module.<br>
<br></div><div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
> structure, sectioning, grouping are the same;<br>
<br>
It's unclear why you think XHTML2's features in this area are better than<br>
HTML5's. Can you elaborate?</blockquote><div><br>"are the same" means that literally there is no difference between XHTML2 and HTML5 about structure, sectioning and grouping of text <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
> text is very similar: you don't have time, but you can have <span<br>
> datatype="xsd:date" content="2008-12-21">Today</span> as in HTML5 you have<br>
> <time value="2008-12-21">Today</time>;<br>
<br>
Why is that better? It seems far worse.</blockquote><div><br>Because you can have date, but you can have email, phone number, zip postalcode, that is any data that have specific formats. Or if you are focused on semantic you use property instead of datatype, and you can put there whatever you feel like, not just times, progresses or range values.<br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
> for progress and meter semantic you can use role attribute (for styling<br>
> you always use CSS);<br>
<br>
That would have a terrible accessibility story as far as I can tell.</blockquote><div><br>Why? Implementations will look for elements with role="progress" (imaginary) instead of progress element, and they will read/display/print/whatever the content attribute (same as time) or element's content.<br>
A part from performance, what is the difference between:<br>document.getElementsByTagName("progress")<br>and<br>document.querySelectorsAll("[role=progress]") or document.evaluate("[@role=progress]");<br>
(not sure about XPath syntax, btw)<br><br>when searching for progress elements to get their semantics?<br>The same obviosly with any element<br><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
This is an area where we are mostly just constrained by legacy -- <ins><br>amd <del> are from HTML4, not new in HTML5.<br></blockquote><div><br>See below <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
> embedding is much more powerful as any element can be replaced by<br>
> embedded content;<br>
<br>
This isn't more powerful, it's more buggy. Just compare <object> with<br>
<img>. Making things general is something that language designers often<br>
feel is a good way to solve many problem at once, but usually it just ends<br>
up not solving any of the problems well. For example, XHTML2 doesn't have<br>
anything like <video>'s APIs.<br>
</blockquote><div><br>See below (i want to summarize all related issues) <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
> tables are the same (you don't have tables API; but you can still use<br>
> DOM3Core);<br>
<br>
Tables in HTML5 are mostly unchanged from HTML4.</blockquote><div><br>Yet, I wrote "are the same" but you (willfully or not) ignored it <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
> XForms are actually more powerful than WebForms2, since you divide<br>
> presentation from data from action (that is implemented declaratively);<br>
<br>
XForms were the original motivation behind HTML5 -- they don't solve the<br>
problem that HTML5 tries to solve, which is the ability to add new<br>
features to existing documents.</blockquote><div><br>See below. <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> interactive elements are not needed at all: details is better implemented as<br>
> it is now (ECMAScript3 + CSS3),<br>
<br>
That has a terrible accessibility story.</blockquote><div>Interaction is by definition not always accessible (how to interact with projected slides or how to use mouse with handhelds) <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> datagrid is just a way to put data in a tree model: use plain XML for<br>
> that;<br>
<br>
How would that be used by, for example, GMail? Gmail today doesn't have a<br>
way to show a list control of all your e-mail without loading all your<br>
mail; <datagrid> allows it.</blockquote><div>GMail works today. And today <datagrid> is not supported. Conclusions?<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> command and a in XHTML2 implemented in any element using href attribute;<br>
> menu is mostly an ul with some style;<br>
<br>
I think you misunderstand <command> and <menu>. Does XHTML2 have anything<br>
for context menus and native toolbars?</blockquote><div>1) for native toolbars and drop down menus you can use CSS3UI appereance property<br>2) for context menus see below<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> scripting uses XMLEvents and handler: it looks the same, but it is<br>
> different as it is more event oriented (scripts are not executed by<br>
> default, they're executed when some event fires)<br>
<br>
Scripting in HTML5 is mostly just describing what we have today, which we<br>
need to keep for backwards-compatibility.</blockquote><div><br>See below <br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> [5, 6, 7 not listed in original e-mail]<br>
><br>
> 8) HTML Syntax<br>
><br>
> 8) as I said before, use XML for that<br>
<br>
This doesn't seem to solve many of the problems being faced by developers<br>
today, and ignores many of our requirements, such as backwards-<br>
compatibility, and the desire for incremental improvements only.</blockquote><div><br>See below <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
> What I am asking now is so to "modularize HTML". copy those features<br>
> into separate, interoperable modules, removing legacy features (like<br>
> window.on-whatever event listener)<br>
><br>
> A copy of those will remain in HTML5, because browser implement them at<br>
> the moment, and the HTML5 goal is that all browser implement the same<br>
> things in the same ways<br>
><br>
> Instead, some web developers in the future will think that a modularized<br>
> and less redudant API is more usable, like I personally do, and switch<br>
> to that, without mixing with HTML5: actually, I guess what a Database<br>
> API does inside HTML.<br>
<br>
Some parts of HTML5 are indeed going to be split out into separate specs,<br>
but unless you know someone who can actually edit these other specs, it's<br>
not going to happen any time soon.<br>
<br>
See also:<br>
<br>
<a href="http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html" target="_blank">http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html</a><br>
<br>
<br>
</blockquote></div></div><br>(eventually, now I will explain all "see below"s)<br><br>As I said in the previous email, I'm not asking for any changes in the current HTML5 specification. The are too many websites that rely on current browser features, we cannot simply mark them as invalid (most of them are invalid actually).<br>
But my concerns are for new web applications.<br><br>When I write something completely new, I don't care of backward-compatibility with existing web sites. Instead I want to use the best and latest features available to write my brand new website.<br>
I can then use XML ignoring the fact that browser must support HTML serialization. I can avoid <b> and <i>, because these are not defined in XHTML2, ignoring the fact that many websites rely on them to style themselves.<br>
I can use <?xml-stylesheet ?> ignoring that browsers will also accept <link rel="stylesheet">. I can use the new XHTML2 (dated feb/06) namespace ignoring the fact that browsers will also process elements in 1999 XHTML 1.0 namespace. I can use XMLEvents 2 ignoring the fact that browsers will also use on-whatever as event handlers, and <script> content will be treated as ECMAScript 3<br>
<br>But there are features that cannot be handled ignoring HTML5:<br>1) plugin-specific message syntax (I mean another way to see the video API, just target.contentWindow.postMessage("stop") instead of target.stop() )<br>
2) What binding must expose in global scope, a part from binding specific features (like Infinity or Nan in ECMA3/4): this may be addressed in XMLEvents 2 or XBL2, that add the ability to put interactivity in XHTML2<br><div id=":3" class="ArwC7c ckChnd">
3) the Window object (which includes window name, window location, cross document messaging, dialog windows)<br>4) Protocol and Content Handlers<br>5) Session and Local storage<br>6) Database storage<br>7) Drag and Drop<br>
8) WebSockets</div><br>These modules are not restricted to backward-compatible web browsers (i.e. HTML5 conforming user agents), they are general purpose and because of this they must get copied from HTML5 in a lite fashion (ie. removing the most legacy or duplicated features) without unnecessary requirements.<br>
(For example, why CSSOM Views depends on HTML5? All CSS compatible application must implement HTML5?)<br><br>Yes, it is a long and difficult work, and we need an editor. But I'm not asking you to do it tomorrow. Since this work is looking very long in the future, specifications are not needed immediately. But if you never produce them, new web applications will be exactly the same as now.<br>
<br>Giovanni<br><br>PS: what we probably need now is more implementation of current W3C Reccomandations like XForms 1.0, instead of running behind the latest HTML5 Editor's Drafts)<br>