On Jun 1, 2007, at 02:31, Ian Hickson wrote:
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.
OK.
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?
The section is now 3.17.1.1. Script languages. (The section numbering
in the email you quoted is from the 2006-02-24 revision of the spec.)
The linked draft has become http://www.ietf.org/rfc/rfc4329
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.
It was about <datagrid>.
Is it better now?
I think the non-normative intro section still doesn't sufficiently
cover the relationship to the DOM and the CSS frame tree.
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.
It wasn't clear to me why the spec specified datagrid as part of
required UA functionality instead of e.g. Google shipping an Open
Source JavaScript library that implements the whole thing using
existing stuff available in browsers. Is this about particular native
widgets? About performance?
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?
I thought there might be a requirement that the content made sense as
a data model.
Do you think it should be further restricted?
Not necessary, I guess.
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?
Yes. Thanks.
--
Henri Sivonen
[EMAIL PROTECTED]
http://hsivonen.iki.fi/
