[whatwg] Parsing, syntax, and content model feedback

[Ian Hickson]

On Thu, 25 Dec 2008, Giovanni Campagna wrote:
> >
> > 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.

This doesn't seem to affect developers of Web applications.


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

Yes, but it's unclear how the model XForms uses would work with HTML forms 
and how they would be better than what we have in forms in HTML5 now. 
(XForms was carefully studied in the development of, and indeed was the 
inspiration for, HTML5's form features.)


> Btw, I meant the first part of HTML5 spec (parsing of date - time - 
> numbers - etc.)

I don't understand how XML Schema data types would be helpful here.


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

I guess I don't understand what you are proposing if what I said doesn't 
make sense. I thought you were suggesting using binding specific features 
instead of DOMStringMap, but DOMStringMap is basically nothing but a 
convenient way of referring to binding specific features.


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

Actually Microsoft.

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

There is no need for special syntax to support the ability for 
organisations to collaborate on extending the specification in a uniform 
and global manner. HTML4 was a W3C specification, yet the WHATWG extended 
it with HTML5, for instance.


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

But what problem does this solve?


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

The idea of <time> isn't to allow you to encode semantics, the idea is to 
allow you to encode a time that can then be rendered in a locale-aware 
manner. E-mails, phone numbers, and postal codes don't have 
locale-specific manners in which they are presented -- a US number is 
written the same in the UK, and a Swiss postal code is written the same in 
Norway. The presentation is tied to the locale of the value, not the user.


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

Then what's the benefit?


> Apart 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 first is far simpler.


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

<details> is accessible (it can be optimised for whatever media the user 
is using). That's the whole point of introducing the feature.


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

GMail today doesn't have a way to show a list control of all your e-mail 
without loading all your mail.


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

The presentation layer and the semantic layer are very separate. If doing 
things with CSS and JS only was acceptable, we could replace all of HTML 
with just <div> and <embed>.


> As I said in the previous email, I'm not asking for any changes in the 
> current HTML5 specification.

This mailing list's only purpose is discussing changes to the HTML5 
specification. That's why I assume e-mails are on that topic. :-) If you 
don't want changes, this may be the wrong forum.


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

If you are asking that these sections be removed from HTML5 and placed 
into separate specs, then this is now done for numbers 5, 6 and 8 on your 
list. Numbers 1, 2, 3, 4, and 7 are too tightly related to the core HTML 
features to ever be split out sanely IMHO.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'