- From: Thomas Broyer <t.broyer@gmail.com>
- Date: Wed, 1 Aug 2007 20:01:30 +0200
- To: public-html@w3.org
2007/8/1, Robert Burns:
>
> On Aug 1, 2007, at 10:57 AM, Thomas Broyer wrote:
> >
> > I think it's about documents with multiple namespaces, where XHTML5 is
> > an "embedded language" (e.g. an Atom feed). In this case, you'd like
> > to be able to assemble XHTML fragments from different sources and
> > don't have their @id's conflict.
> > I think "subtree" here means "subtree rooted at the 'root element'",
> > not "subtree rooted at the element bearing the id attribute".
> > ...just my own understanding, because I couldn't think of any other
> > meaning for this sentence.
>
> Given that and what you say in the next two blocks, are you then
> saying that we make no assumptions that an @id is of type ID?
Yes. @id is NOT of type ID.
> This may be similar to me getting my head around the no versioning idea,
> but I sense you're saying HTML5 has some kind of weak typing. Is that
> correct? That would explain why there's little mention of data types.
> So if the HTML5 @id attribute is not of type ID but rather simply a
> string, we can deploy whatever uniqueness rules we want (even in XML).
As far as "content attributes" are concerned, they're just "strings"
(DOM's getAttribute and getAttributeNS return DOMString-typed values).
"Datatyping" is only done when extracting typed values for rendering
or reflected attributes on the DOM interfaces or extracting semantics.
It is that way because of HTML's error recovery (errors are never
fatal): attributes might have invalid values but those errors are
recovered when "casting" the value (to e.g. a number or datetime).
> > Given that valid HTML4 and XHTML 1.0 documents would still be valid
> > (X)HTML5 documents, I don't see the problem.
>
> Well my concern would be that an HTML4 UA might have taken this
> portion of the HTML4 recommendation seriously and the compatibility
> would be broken (if testing has already indicated that's not the
> case, then I'm satisfied on that).
If such an UA exists, it cannot work on the web today, because
published content is broken.
For styling:<!DOCTYPE html>
<style>
#\30, #\24\5e\7C, #foo\ bar { color: blue; font-weight: bold; }
</style>
<p id=0>0<p id=$^|>$^|<p id="foo bar">foo bar</p>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%23%5C30%2C%20%23%5C24%5C5e%5C7C%2C%20%23foo%5C%20bar%20%7B%20color%3A%20blue%3B%20font-weight%3A%20bold%3B%20%7D%0A%3C/style%3E%0A%3Cp%20id%3D0%3E0%3Cp%20id%3D%24%5E%7C%3E%24%5E%7C%3Cp%20id%3D%22foo%20bar%22%3Efoo%20bar%3C/p%3E
Firefox 2.0.0.6: everything's blue.
IE7: foo bar is blue only if you write #foo\000020bar, others are blue.
Opera 9.22: everything's blue
For scripting:
<!DOCTYPE html>
<body>
<p id=0><p id=$^|><p id="foo bar"></p>
<script>
var paras = document.getElementsByTagName("p");
for(var i = 0; i < paras.length; i++) {
w("paras[" + i + "].id = " + paras[i].id);
var p = document.getElementById(paras[i].id);
w((p === paras[i] ? "Found" : "NOT found") + " using getElementById.");
}
</script>
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C%21DOCTYPE%20html%3E%0A%3Cbody%3E%0A%3Cp%20id%3D0%3E%3Cp%20id%3D%24%5E%7C%3E%3Cp%20id%3D%22foo%20bar%22%3E%3C/p%3E%0A%3Cscript%3E%0Avar%20paras%20%3D%20document.getElementsByTagName%28%22p%22%29%3B%0Afor%28var%20i%20%3D%200%3B%20i%20%3C%20paras.length%3B%20i++%29%20%7B%0A%20%20%20w%28%22paras%5B%22%20+%20i%20+%20%22%5D.id%20%3D%20%22%20+%20paras%5Bi%5D.id%29%3B%0A%20%20%20var%20p%20%3D%20document.getElementById%28paras%5Bi%5D.id%29%3B%0A%20%20%20w%28%28p%20%3D%3D%3D%20paras%5Bi%5D%20%3F%20%22Found%22%20%3A%20%22NOT%20found%22%29%20+%20%22%20using%20getElementById.%22%29%3B%0A%7D%0A%3C/script%3E
Expected output:
log: paras[0].id = 0
log: Found using getElementById.
log: paras[1].id = $^|
log: Found using getElementById.
log: paras[2].id = foo bar
log: Found using getElementById.
Firefox 2.0.0.6: OK
IE7: OK
Opera 9.22: OK
Not tested on other browsers.
> Will we not have an XML schema of any kind (DTD, XSD or otherwise)?
If we finally do, it'll have to cope with the rules defined in the
prose (not the opposite).
> Should we include something in this subsection explaining that an @id is
> not of type ID?
Maybe.
--
Thomas Broyer
Received on Wednesday, 1 August 2007 18:01:35 UTC