[x3d-public] id attribute proposal
Don Brutzman
brutzman at nps.edu
Tue Mar 29 20:43:01 PDT 2016
An interesting relevant example in HTML4/HTML5 is the evolution of the Anchor tag <a>.
In HTML4.01, both name and id attributes are allowed.
======================================================
https://www.w3.org/TR/html4/struct/links.html#h-12.2.1
12.2.1 Syntax of anchor names
An anchor name is the value of either the name or id attribute when used in the context of anchors. Anchor names must observe the following rules:
Uniqueness: Anchor names must be unique within a document. Anchor names that differ only in case may not appear in the same document.
String matching: Comparisons between fragment identifiers and anchor names must be done by exact (case-sensitive) match.
Thus, the following example is correct with respect to string matching and must be considered a match by user agents:
<P><A href="#xxx">...</A>
...more document...
<P><A name="xxx">...</A>
======================================================
Looking in HTML5 specification, the "name" attribute is not mentioned. Further it is quite difficult to find where a URL bookmark ending in #bookmarkName is defined for the anchor tag - there is a lot of dense prose, but still haven't found where it is specified.
A summary can be found here:
======================================================
http://www.w3schools.com/tags/att_a_name.asp
HTML <a> name Attribute
The <a> name attribute is not supported in HTML5. Use the id attribute instead.
======================================================
======================================================
http://www.w3schools.com/tags/tag_a.asp
HTML <a> Tag
Definition and Usage
The <a> tag defines a hyperlink, which is used to link from one page to another.
The most important attribute of the <a> element is the href attribute, which indicates the link's destination.
======================================================
An anchor tag can also include the attribute rel='bookmark' which indicates that the relationship of the href is to link to a bookmark.
HTML5 relative-link example:
======================================================
http://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_a_href_anchor
<h2 id="top">Top of page!</h2>
...
<a href="#top">Go to top</a>
======================================================
Looking over all of the interesting information which is being collected, carefully keeping DEF and id as separate but intertwined/correlated concept definitions might have a number of advantages.
At this point it is beginning to seem like the following design goals might be defined and met:
- Coexistence: DEF/USE syntax and semantics remain perfectly OK for ROUTE and Script usage within an X3D scene graph that itself is a DOM fragment.
- Independence: The unique id attribute allows external HTML scripts up in the document DOM to operate independently of any internal X3D activity.
- Integration: Conceivably, fallback rules for correlating id/DEF might allow for graceful integration: loading a legacy X3D v3 scene into DOM doesn't require authors to perform intentional addition of duplicative id attributes before passing events.
- Separation: once an event is within an X3D scene graph, X3D semantics apply.
Not sure the X3DOM rules do that precisely, but they might be adapted to support these goals of coexistence, independence and integration.
For example, perhaps additions might state things like:
- The DOM requires that all id values are unique.
- If a DOM event is passed from the DOM to an X3D scene that does not have a matching target id attribute, then the matching DEF attribute identifies the target node instead.
- A DOM event cannot be passed from the DOM to an X3D scene fragment that does not have a matching id or DEF attribute; it is ignored.
- An X3D event can be passed within the X3D scene graph or externally to the DOM, if no matching X3D DEF is present and a matching id is found.
- For identical (internal) DEF and (likely external) id names, the DEF name takes precedence when routing X3D events.
Encouraging design progress and dialog so far... examples and alternatives certainly help inform our understanding. To further increase clarity, we might build specific examples to illustrate each potential rule.
Nevertheless we still have a ways to go, several tricky issues are still open:
- How are SVG and MathML included and integrated within DOM?
- How are HTML5 scripts and canvas objects integrated within DOM?
- Need to list and illustrate all event-passing techniques from an external DOM tree into an X3D fragment.
- Determine whether the X3D fragment needs a separate namespace, or can adequately be referenced via simple xpath expressions.
- Determine whether the embedded "X3D namespaces" such as DEF/USE within a prototype or inline be unique, or ignored, or have specific prefixes.
One more observation: isn't it interesting how a relatively "easy" id attribute proposal leads in all these many directions! 8)
v/r Don
On 3/23/2016 8:00 PM, Andreas Plesch wrote:
> ad a.
>
> Statements such as ROUTE cannot have DEF fields, right ? What other potential DOM elements cannot have a DEF field ?
> Are these accessible by the SAI ?
>
> ad c.
>
> Although I cannot speak for Behr et al., I believe the x3dom rules meant to make it possible to separate x3d naming from DOM naming and keep x3d naming from interfering with DOM naming outside of x3d if so desired.
>
> I think, in practice this desire almost never materializes since the point of x3dom is to integrate x3d into the DOM. So the rule most often has the effect that it becomes necessary to assign DEF and id identical values.
>
> Andreas
>
> On Mar 20, 2016 11:53 PM, "Andreas Plesch" <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>> wrote:
>
> a.
>
> It may work to just declare in the spec. that the DEF value becomes the value of the id attribute when the node is interpreted as a DOM element. This way it may not be required to add an explicit id field to each node. However, it does seem narrow minded if simply adding an id attribute invalidates a x3d file.
>
> b.
>
> The default value for an explicit id field if deemed required could be the value of the DEF of the node.
>
> c.
>
> x3dom has both id and DEF attributes.
> If both id and DEF are set both attributes will have different values.
> If only DEF is given id is unset.
> If only id is given DEF and id will be set.
> http://examples.x3dom.org/example/x3dom_defUse.xhtml
>
> In addition, to allow working with valid x3d files, x3dom has an attribute for inline nodes MapDEFtoID which generates the ID value from the DEF value.
>
> d.
>
> Cobweb does not use the DOM for x3d.
>
> id is important for DOM compatibility and needs to be addressed in some way if x3d nodes are to be integrated in the DOM. If not, there needs to be clarification as well that x3d is not intended to be compatible with DOM use which would be a missed opportunity in my view.
>
> Before we think about class we need to deal with id I think.
On 3/20/2016 2:33 PM, Don Brutzman wrote:
> Obvious questions:
>
> a. can DEF/USE simply be utilized instead? First law of engineering: "if it isn't broken, don't fix it."
>
> b. if DEF/USE cannot or ought not to be utilized, then how is is backwards compatibility handled? This includes Inline content loaded into a parent scene.
>
> c. what does X3DOM currently do?
>
> d. what does Cobweb currently do?
>
>
> On 3/20/2016 10:09 AM, John Carlson wrote:
>
> I'll second the proposal. Also I'd like to propose adding CSS selectors for values of the fromNode and toNode attributes on ROUTEs if not already in the standard. Thus if you have a node with id="foo" you could use a route with toNode="#foo". Class attributes would work similarly for fan in fan out.
>
> John
>
> On Mar 20, 2016 11:23 AM, "Andreas Plesch" <andreasplesch at gmail.com <mailto:andreasplesch at gmail.com> <mailto:andreasplesch at gmail.com <mailto:andreasplesch at gmail.com>>> wrote:
>
> Since Don mentioned that nobody has proposed introducing an 'id' attribute, let me then propose adding an 'id' SFString attribute to all nodes for x3d 4.0.
>
> The reason is simply compatibility with the DOM on web pages in the case where x3d nodes are interpreted as DOM elements.
>
> Andreas
> [...]
all the best, Don
--
Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu
Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman
More information about the x3d-public
mailing list