[whatwg] More comments and questions on Web Apps 1.0

Thu May 31 16:31:36 PDT 2007

On Mon, 20 Mar 2006, Henri Sivonen wrote:
> 
> 1.14.1.
> The style and script elements in XHTML have a potentially anything goes 
> content model. Would it be appropriate for a conformance checker to only 
> pass style and script types it knows about (with the proper content 
> model for each type)?

I would expect a conformance checker to have a "could not validate" mode 
which was between "no" and "yes", though presented more like "no", for the 
state where there was no actual error, but something that normally can be 
checked couldn't be verified for whatever reason.

> 2.14.1.1.
> The spec should probably mention
> http://www.ietf.org/internet-drafts/draft-hoehrmann-script-types-03.txt or its
> successor around here.

I have no idea which section that was, nor which RFC that is (the URI is 
now dead). Is there an updated link?

> 2.17. & 2.18.
> Are calendars and cards expected to be unstylable replaced elements in
> rendering?

Those sections are gone now.

> 2.20.1.
> When I read this, I had trouble organizing (in my mind) what I was reading
> because I had no prior understanding of where the spec was going. Up to this
> point, I had had prior hypotheses that were confirmed or disconfirmed by the
> spec. This section would be a lot easier to read if it had an introductionary
> paragraph stating the relationship of rendering, the DOM, the data model
> object and data submission. (Is the DOM being rendered or is a replaced widget
> element being rendered? Is it stylable? Is the data model reflected back to
> the DOM? What's the expected way of serializing the data model and sending it
> back to the server?)

I don't know which section this is talking about. Is it better now? Since 
last year I've made several attempts at making the spec flow better.

> 2.20.1.
> Also, I wondered whether this functionality is best specced as part of the UA
> or whether it would be better to ship it as a MIT/expat-licensed pure-JS
> library for running on top of the lower-level JS/DOM APIs. (Note: Considering
> what I wrote above, I don't really understand what the aims are, so I may be
> totally missing the point.)

Not sure what you mean.

> 2.20.1.3.
> I had trouble trying to extract markup-level conformance requirements for
> stuff that can occur inside the datagrid.

It's just any block-level content. Why was it unclear? Do you think it 
should be further restricted? I've made it explicit.

> 2.20.1.3.
> Is select allowed to occur in the block context only here or anywhere?

Oops. Allowed <select> now. (<datalist> too.)

> 2.20.2.
> Is command in head conforming in the XHTML serialization only? (It is a
> phasing element in the tree construction section.)

At some point I'll put <command> in the <head> in the parser, I think. 
Otherwise, it'll be allowed in the <head> in XHTML only (or not at all).

> 2.20.3.
> It why not use type="context" for declaring a context menu?

Yeah, I guess that's fine. Changed.

> 3.1.
> "We could make this into a string value that acts as a Hint for why the
> command is disabled."
> 
> I suspect that to be trouble, because general purpose code for dealing 
> with boolean attributes would need to take that special case into 
> account. Using another attribute for a hint would be fine, though.

The reason to have the boolean be the string would be to force authors to 
provide the hint. You could easily provide the hint using "title", the key 
is to find a way to force authors into writing good code.

> 4.4.1.
> "Since all HTML elements can thus be focused and unfocusd"
> 
> unfocused

Apparently this went away.

> 4.5.
> Is onerror only a DOM attribute or is it a markup attribute as well? Whose
> attribute is it?

Is this defined to your satisfaction now?

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