[whatwg] Parsing, syntax, and content model feedback

2008/12/25 Ian Hickson <ian at hixie.ch>

>
> We're very constrained by the legacy for text/html's syntax; sadly,
> usability concerns aren't really able to make us change the language.
>
> [...]
>
> The goal is not to guess what the author meant when the authors makes a
> mistake; the goal is to have interoperable, predictable, defined behavior
> for all input.
>
> [...]


See below

>
> Could you elaborate on how spec design like XHTML modularisation has any
> impact on developers of Web applications? I was under the impression that
> the only benefit was in the development of other specs based on the
> modules (and that only if those needs happened to mesh with the particular
> modules picked).
>

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.

I assume you mean in forms?
>
> > 1) use XMLSchema datatypes
>
> It's unclear how XML Schema datatypes would work with HTML forms and how
> they would be better than what we have in forms in HTML5 now.


XForms use XMLSchema datatypes (default or user-defined). Btw, I meant the
first part of HTML5 spec (parsing of date - time - numbers - etc.)

>
>
> > 2) additional DOM interfaces, which include HTMLElement - HTMLCollection
> -
> > HTMLFormsControlCollection - HTMLOptionsCollection - DOMTokenList -
> > DOMStringMap
> >
> > 2) you don't need HTMLElement: markup insertion, attributes querying can
> > be done using DOM3Core (that in latest browser are even more performant
> > as no parser is involved), events are far better handled by DOM3Events,
> > styling is included by CSSOM
> >
> > you don't need collection either: just use appropriate DOMNodeLists,
> > while for DOMStringMap you may use binding specific features (all Object
> > are hash maps in ECMAScript3): it works this way even in HTML5
>
> Both HTMLElement and collections are in DOM2 HTML (even DOM1 HTML).
>
> DOMStringMap is basically nothing but a binding-specific feature.


I don't see your point


> XHTML2 is not backwards compatible, and was a big part of the motivation
> behind starting the HTML5 effort.
>

Still, see below.


> Extensibility is an anti-feature -- we specifically don't _want_ people to
> extend HTML without working with the wider community. That way lies
> fragmentation of the language and lack of interoperability. Indeed, what
> little non-centralised extension HTML has seen -- <spacer>, <blink>,
> <marquee> -- has been widely decried as a disaster.


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


> > structure, sectioning, grouping are the same;
>
> It's unclear why you think XHTML2's features in this area are better than
> HTML5's. Can you elaborate?


"are the same" means that literally there is no difference between XHTML2
and HTML5 about structure, sectioning and grouping of text


>
> > text is very similar: you don't have time, but you can have <span
> > datatype="xsd:date" content="2008-12-21">Today</span> as in HTML5 you
> have
> > <time value="2008-12-21">Today</time>;
>
> Why is that better? It seems far worse.


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.


>
> > for progress and meter semantic you can use role attribute (for styling
> > you always use CSS);
>
> That would have a terrible accessibility story as far as I can tell.


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.
A part from performance, what is the difference between:
document.getElementsByTagName("progress")
and
document.querySelectorsAll("[role=progress]") or
document.evaluate("[@role=progress]");
(not sure about XPath syntax, btw)

when searching for progress elements to get their semantics?
The same obviosly with any element

This is an area where we are mostly just constrained by legacy -- <ins>
> amd <del> are from HTML4, not new in HTML5.
>

See below

>
>
> > embedding is much more powerful as any element can be replaced by
> > embedded content;
>
> This isn't more powerful, it's more buggy. Just compare <object> with
> <img>. Making things general is something that language designers often
> feel is a good way to solve many problem at once, but usually it just ends
> up not solving any of the problems well. For example, XHTML2 doesn't have
> anything like <video>'s APIs.
>

See below (i want to summarize all related issues)

>
> > tables are the same (you don't have tables API; but you can still use
> > DOM3Core);
>
> Tables in HTML5 are mostly unchanged from HTML4.


Yet, I wrote "are the same" but you (willfully or not) ignored it

>
>
> > XForms are actually more powerful than WebForms2, since you divide
> > presentation from data from action (that is implemented declaratively);
>
> XForms were the original motivation behind HTML5 -- they don't solve the
> problem that HTML5 tries to solve, which is the ability to add new
> features to existing documents.


See below.

> interactive elements are not needed at all: details is better implemented
> as
> > it is now (ECMAScript3 + CSS3),
>
> That has a terrible accessibility story.

Interaction is by definition not always accessible (how to interact with
projected slides or how to use mouse with handhelds)


> > datagrid is just a way to put data in a tree model: use plain XML for
> > that;
>
> How would that be used by, for example, GMail? Gmail today doesn't have a
> way to show a list control of all your e-mail without loading all your
> mail; <datagrid> allows it.

GMail works today. And today <datagrid> is not supported. Conclusions?


> > command and a in XHTML2 implemented in any element using href attribute;
> > menu is mostly an ul with some style;
>
> I think you misunderstand <command> and <menu>. Does XHTML2 have anything
> for context menus and native toolbars?

1) for native toolbars and drop down menus you can use CSS3UI appereance
property
2) for context menus see below


> > scripting uses XMLEvents and handler: it looks the same, but it is
> > different as it is more event oriented (scripts are not executed by
> > default, they're executed when some event fires)
>
> Scripting in HTML5 is mostly just describing what we have today, which we
> need to keep for backwards-compatibility.


See below


> > [5, 6, 7 not listed in original e-mail]
> >
> > 8) HTML Syntax
> >
> > 8) as I said before, use XML for that
>
> This doesn't seem to solve many of the problems being faced by developers
> today, and ignores many of our requirements, such as backwards-
> compatibility, and the desire for incremental improvements only.


See below

>
>
> > What I am asking now is so to "modularize HTML". copy those features
> > into separate, interoperable modules, removing legacy features (like
> > window.on-whatever event listener)
> >
> > A copy of those will remain in HTML5, because browser implement them at
> > the moment, and the HTML5 goal is that all browser implement the same
> > things in the same ways
> >
> > Instead, some web developers in the future will think that a modularized
> > and less redudant API is more usable, like I personally do, and switch
> > to that, without mixing with HTML5: actually, I guess what a Database
> > API does inside HTML.
>
> Some parts of HTML5 are indeed going to be split out into separate specs,
> but unless you know someone who can actually edit these other specs, it's
> not going to happen any time soon.
>
> See also:
>
>   http://lists.w3.org/Archives/Public/public-html/2008Oct/0127.html
>
>
>
(eventually, now I will explain all "see below"s)

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).
But my concerns are for new web applications.

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

But there are features that cannot be handled ignoring HTML5:
1) plugin-specific message syntax (I mean another way to see the video API,
just target.contentWindow.postMessage("stop") instead of target.stop() )
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
3) the Window object (which includes window name, window location, cross
document messaging, dialog windows)
4) Protocol and Content Handlers
5) Session and Local storage
6) Database storage
7) Drag and Drop
8) WebSockets

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.
(For example, why CSSOM Views depends on HTML5? All CSS compatible
application must implement HTML5?)

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.

Giovanni

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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081225/ecf8502d/attachment.htm>

Received on Thursday, 25 December 2008 09:51:52 UTC