- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 7 Jan 2005 16:06:20 +0000 (UTC)
On Sat, 1 Jan 2005, Bill McCoy wrote:
>
> This is a response to the Dec. 10 call for final comments on the Web
> Forms 2.0 propoal.
Thanks for your feedback!
> 1. The proposal is unclear about what it is extending. The proposal
> defines Web Forms as "an extension to the forms features found in
> HTML 4.01's Forms chapter" and that the "specification clarifies and
> extends the semantics put forth in [HTML4]". Yet, the specification
> includes substantive extensions to DOM and implications for CSS,
> neither of which are part of HTML4.
Good point. The proposal is an extension to HTML4, XHTML1, and DOM2
HTML; I have updated the abstract and introduction sections to make
this clearer.
> The spec also appears to cover browser-based rendering of
> CSS-styled/scripted XML.
In general the intention si that this proposal avoids giving any specific
conformance criteria related to rendering; which sections were you
thinking of in particular?
> It appears from the spec and charter that the intention of WHATWG is to
> define Web Forms as an extension to what Opera calls "Street HTML", and
> defines as "the real HTML that is used on the millions of sites on the
> Internet". In other words, WHATWG appears to be proposing to extend the
> de facto Web platform of HTML+CSS+DOM+JavaScript, as implemented by
> browsers prevalent circa 2004, not just HTML. If so why not explicitly
> state this expectation?
The lack of such a statement was an oversight. Please let me know if the
new text is more to your liking.
> 2. So what is "Street HTML" anyway?
I have no idea, that's why I never used the term "Street HTML" in the spec
or in any of the pages on the WHATWG site. :-)
> Is the "outerHTML" property in or out?
Probably out, but that hasn't been discussed yet. The relevant section is:
http://whatwg.org/specs/web-apps/current-work/#serialization
Suggestions are welcome.
> What are its error handling rules, exactly?
Currently this is defined in:
http://whatwg.org/specs/web-forms/current-work/#handling
...but if you see any errors whose error-handling rules are not
covered, please let me know so we can define them.
> Is client-side XSLT part of the platform?
WHATWG doesn't currently define which specifications form part of "the
platform" per se.
> WHATWG proposes to add a couple dozen new HTML attributes, several new
> HTML elements and DOM interfaces, a bunch of new DOM interfaces and
> attributes, and changes to the content model and semantics of existing
> HTML, CSS, and DOM facilities. Are you really proposing to take an
> ill-defined spec and bolt on all this additional complexity?
We are proposing to take the ill-defined specs, make them well-defined,
and then bolt on the additional features.
> Wouldn't it be more appropriate to first, as constituting three of the
> four leading browser manufacturers, clearly define what is this "real
> HTML" platform? You would be doing the community a real service if you
> tackled defining the existing foundation before proposing to in effect
> add-on a another story.
This is indeed a good point. If it was up to me, I would define it as:
Unicode
DOM3 Core
CSS 2.1, including the Bidi algorithm
HTTP, HTTPS (SSL/TLS), Cookies, FTP, DNS, IDN
XML, Namespaces in XML, XML Base, xml:id
Associating Style Sheets with XML documents (the XML Stylesheet PI)
DOM3 Events
HTML, DOM2 HTML
ECMA-262 (JavaScript)
DOM3 Style
DOM2 Traversal and Range
PNG and APNG, GIF and AGIF, JPEG; XBM, BMP, ICO
RFC 2387 (data: URIs)
Selectors
CSS3 UI
WebForms 2.0
CSS3 Color
SVG 1.1, excluding support for XPointer and "SVG view specification" (see
section 17.2.2).
WebApps
Media Queries
XML Events
XBL2
CSS3 Backgrounds and Borders
CSS3 Cascade and Inheritance; CSS3 Values and Units
CSS3 Generated Content
CSS3 Lists
MathML
CSS3 Columns
...but that's just my personal opinion and I am aware that it does not
represent what other Opera, Mozilla, and Apple employees think should
be "the platform". Several of the specs above are incomplete right
now, too.
The W3C Compound Document Formats working group could be a better
forum to discuss this, although that group is currently more focused
on future-looking XML-biased solutions than backwards-compatible
HTML-capable worlds such as the one I describe above.
> 3. Section 1.4 on "Relation to XForms" is confusing. Terms like
> "everyday Web browsers" and "typical Web browsers" are ill-defined.
What term would you use to refer to IE, Opera, Firefox, Mozilla,
Safari, and Netscape? (i.e., user agents that use HTTP and render HTML
content to the user.)
> Also the statement that XForms "has not been widely implemented by
> those browsers" seems odd in this context: XForms is a new spec and
> the proposed Web Forms 2.0 has not been implemented yet either.
Fair point, I have removed this sentence.
> And again WHATWG represents the 2nd, 3rd, and 4th most popular
> browser manufacturers, and XForms has already been implemented as a
> plug-in to the #1 browser, so what this seems to really amount to is
> "we don't want to implement XForms, we want to implement this other
> thing, Web Forms 2.0, instead". If that's your position, why not
> just say so?
I do not believe that specifications are really the appropriate place
for position statements. Whether my employer wishes to implement
XForms or not is not really a matter that is relevant to WHATWG
itself; WHATWG's charter relates to specifying extensions that are
backwards compatible, which is completely unrelated to XForms.
> Also the comment about "dependencies on technologies not widely
> supported by Web browsers" in this section and the introductory
> comment about not requiring "support for other technologies such as
> XPath, XML Schema, or XML Events, as these are not implemented in
> typical Web browsers" seem strange circa 2005. For example XSLT
> builds on XPath and as such XPath (along with XSLT) is already
> supported in the two most popular web browsers. XML Schema is part
> and parcel of SOAP, and is for example already standardized in
> Mozilla/Firefox and through .NET is available in IE platform. So it
> seems that these technologies are already widely supported and that
> this should be a non-issue in the decision whether or not to support
> XForms.
Your point is well taken. I have removed or reworded the sections to
which you refer.
> And of course XForms is designed for client-side execution as a
> major use case and client-side XForms solutions are being
> commercially deployed so at a minimum your diagram is confusing, as
> it should at least show that server transcoding is a backstop for
> XForms support, not the only path.
The diagram is merely showing how Web Forms can be used with XForms,
it does not claim to demonstrate the only way of using XForms. I think
this is clear from the context.
> 4. This is only indirectly covered in the spec, but the assumption
> that the spec should not dictate a plug-in based implementation for
> Internet Explorer is difficult to understand, especially if an
> HTC-based implementation is deemed acceptable. Shortcomings of HTCs
> have been widely discussed in this forum and elsewhere and I know of
> no widely-used production software that uses an HTC-based approach
> to extending Internet Explorer.
http://www.microsoft.com/ is one site that uses HTCs.
The main reason to require that most Web Forms 2 features be
implementable in IE6 without the use of binary plugins is the
significant barrier to entry experienced by binary-based solutions,
especially in the current security climate.
This does not preclude the provision of binary-based Web Forms
implementations, of course.
> Security recommendations for corporate and end users are trending to
> disable "Binary and Script Behaviors", and it would not be
> surprising to see this be the default in the future, so support for
> document-based HTCS may become "doesn't work" or at best devolve to
> the same security model as for plug-ins.
It may be that in the future we have to think of restricting
extensions to only those that can be implemented in pure JavaScript.
However, that much more drastically restricts the possible ways in
which HTML can be extended.
> Rejecting XForms because it would (perhaps) require a plug-in based
> implementation for Internet Explorer seems odd (especially so when
> XForms building-block technologies like XPath and XML Schema are
> already present in this browser platform).
If there are specific extensions you have in mind that would not be
possible using HTCs but would be possible using binary plugins, we
would consider them, and you are encouraged to send them to this list.
Not all the extensions currently in the drafts are implementable using
HTCs, so there is definitely precedent here.
> Alternatively, if you believe a server-based implementation of Web
> Forms 2.0 support for nonsupporting browsers is acceptable (as your
> demos page seems to imply)
No, a server-based approach is not acceptable IMHO. For example, the
whole point of the repetition model is that the client can do the work
without contacting the server. The demos merely demonstrate how Web
Forms 2 features can gracefully degrade in existing HTML UAs while
providing a better experience for Web Forms 2 UAs.
> Whereas Web Forms 2.0, being a script-intensive solution built on an
> ill-defined non-XML language is clearly not going to be nearly as
> easy to handle in server-based workflows. Indeed one of the world's
> largest web sites maintains a large-scale Windows server stack
> merely to run MSHTML server-side. While keeping web documents arcane
> and difficult to process may be a source of commercial advantage to
> browser manufacturers it doesn't seem like a great solution for the
> industry as a whole.
Web Forms 2 is not based on an ill-defined non-XML language, it is
based on a well-defined XML-based language, and merely supports the
HTML form as a backwards-compatible migration path -- in fact there
are several features in Web Forms 2 that only apply to the XHTML world
and not to HTML-based WF2 documents.
Furthermore, Mozilla, Opera, and Safari have all supported XML-based
formats for some time. (For example, Mozilla supported XHTML before
XHTML had been assigned a namespace, it has supported MathML for 4
years or more, its entire UI is based on XUL, which is an XML format,
and it supports client-side XSLT natively.)
I can understand your frustration with authors not migrating to
content sent with XML MIME types, but whether authors decide to
leverage the XML features of Web browsers instead of sticking to the
HTML world that works in a default install of IE6 is not something we
have any control over.
--
Ian Hickson U+1047E )\._.,--....,'``. fL
http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 7 January 2005 08:06:20 UTC