- From: Maciej Stachowiak <mjs@apple.com>
- Date: Fri, 02 Oct 2009 18:58:12 -0700
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: Adrian Bateman <adrianba@microsoft.com>, HTML WG <public-html@w3.org>, Tony Ross <tross@microsoft.com>, Brendan Eich <brendan@mozilla.org>
On Oct 2, 2009, at 6:35 PM, Sam Ruby wrote:
> Maciej Stachowiak wrote:
>> On Oct 2, 2009, at 5:33 PM, Sam Ruby wrote:
>>>> 3) A spec based on Microsoft's proposal could state changes to
>>>> the parsing algorithm, or just define a complete modified copy of
>>>> the parsing algorithm. After all, Namespaces in XML modifies XML
>>>> parsing by modifying the grammar of XML, even though that was
>>>> never an official extension point. I think changes to the HTML5
>>>> parsing algorithm are necessary in some form to fully define
>>>> Microsoft's proposal.
>>>
>>> I would not be in favor of this, but am wondering if there are
>>> small changes to the HTML5 spec that might enable #2 to be
>>> pursued? I won't speculate on what those changes might be.
>> #2 can be pursued with no changes to the HTML5 spec.
>
> I guess I was unclear. If #2 is not viable given the current HTML5,
> the question I was attempting to pose is: what changes would be
> required to HTML5 in order to enable #2 to be viable for the
> remainder?
I think #2 *is* viable given the current HTML5. That was the point of
#2 - what kind of proposals could use the HTML5 "other applicable
specifications" hook with no changes to HTML5 itself. This would
require a different basic design than Microsoft's proposal, which
intrinsically requires parser changes. I suggested two such designs.
Quoting myself from before, with slight corrections:
2) A proposal that only extended the set of conforming elements and
attributes, without changing the parsing requirements, could use the
"other applicable specifications" extension point. Examples of
proposals along these lines:
(a) Use elements and attributes with : in the name, but the DOM is
built as per HTML parsing today, so elements are in the xhtml
namespace and attributes are in the null namespace.
(b) Use the -vendor-prefix pattern used by CSS, instead of colon
syntax, as suggested by Bert Bos.
Now, maybe you are suggesting that HTML5 changes could allow
Microsoft's exact proposal to be expressed in #2 style. I can think of
one possibility - make all of the parser changes required for
Microsoft's proposal, but without making any markup using those
mechanisms conforming. But I think that would not provide any actual
decoupling, and these changes would not be small. Perhaps there is a
clean way to add an extension hook instead, but I cannot think of one
offhand.
> I'm simply motivated to look for ways of decoupling these... both to
> allow HTML5 to proceed unfettered, and to allow the proposal to
> proceed. As an analogy, if there was an insistence that RDFa be
> defined in HTML5 *before* RDFa in HTML was fully defined (and to
> date, it clearly still has a way to go), I don't think we could have
> made the progress to date that we have done.
RDFa is a very successful example of decoupling, and I commend you for
looking for a way to follow the same model. With RDFa this was easy,
because there are no conformance requirements for browsers (unless
they someday choose to extract RDFa information). Microsoft's proposal
is different - would change conformance requirements for browsers,
indeed it would require behavior contrary to the HTML5 parsing
algorithm. That aspect of the proposal cannot readily be decoupled
from the HTML5 spec.
Regards,
Maciej
Received on Saturday, 3 October 2009 01:58:46 UTC