Closed trusktr closed 9 years ago
@trusktr How would having a flat DOM increase control over SEO?
@jd-carroll It would decrease with flat structure. I updated my comment. (:
cc: @alexanderGugel @michaelobriena @redwoodfavorite @oldschooljarvis
I think I'm more confused now.. I need to do some more research on how DOM structure impacts SEO.
So is your idea to provide a feature that would intentionally decrease SEO?
@jd-carroll Not exactly. The feature would let us choose how we structure our DOM (some DOM structures have meaning for SEO, and other structures can be better for technical reasons depending on how we want to render and manipulate things in 3D space using Famous Engine). The feature wouldn't affect SEO in any one way specifically, it would simply give us the option to determine how DOM elements are nested by Famous Engine. The ability to control the DOM nesting structure could impact SEO negatively or positively depending only on our choice of DOM structure. The feature would merely give us more control over that final structure of the DOM.
I don't know if having a flat DOM is a priority right now. I can see a use case for it, but it would require significant changes in DOMRenderer, the way it handles paths, the TransformSystem etc.
I also very strongly believe that having an extremely flat DOM is something that should be thought about twice before using it. Not just because of SEO, but primarily because of accessibility. From my understanding, having a nested DOM with a nice document structure makes it much easier for people that depend on screen readers and braille displays to navigate your app. Making your DOM flat, means they just get a very long list of probably completely unrelated elements.
but primarily because of accessibility
Also for performance too. With nested DOM, transforms (in Chrome, but not IE11?) apply from the parent's frame of a reference, so (in Chrome) a rotation on a parent means you only have to apply a matrix3d to the parent. The power of this is that for nested DOM a parent element is a transform cache for all its children. I don't know if MS is already tackling this or not, but I made an IE bug report just in case.
but primarily because of accessibility
Just like with traditional development using HTML, accessibility could be positive or negative depending on the structures we choose. Option 1 would just give us more freedom in how we balance SEO/accessibility with performance and functionality.
@trusktr's first suggestion is interesting.
With it, you'd still have DOM nesting, and partial matrix transformation inheritance/caching. In situations where you had a DOMElement attached to a descendant node, with an ancestor node that contained a void DOMElement, the descendant DOMElement would simply nest within the first available non-void DOMElement in the hierarchy.
The upshot is the scene graph would require fewer nodes in many situations, and it would feel far more natural to use. Could also achieve flat DOM if desired just by tellng everything to not nest.
Potential downsides include breaking 1:1 DOM/scene graph correspondence (though arguably that isn't necessarliy a bad thing, plus setContent() already breaks it anyways), and driving @DnMllr insane at the notion of another DOMRenderer refactor.
IMHO the current system works, even if it's a bit verbose on the scene graph side.
@trusktr This is probably something we will not do. You have the ability to get a flat DOM if you manage it yourself. Whenever you want to add a DOMElement to a Node, just make a dangling child and add the DOMElement to that. This would ensure that you have flat DOM all the way down.
I don't really see any large positives in allowing for flat DOM and just adds unneeded complexity to the system.
Closing as we will not be implementing this.
Based on #226, a couple of ideas:
DOMElement
would make sense:domElement.useNesting(false)
? When we've setuseNesting(false)
then children DOMElements of theuseNesting(false)
DOMElement would be placed as siblings to theuseNesting(false)
DOMElement in the DOM hierarchy.Either option would present us with something to think about: more or less SEO depending on the DOM structure. With option 1, being able to have a mix of flat and nested levels would give us the ability to balance SEO with how rendering happens. In #226, for example, nesting Nodes is useful for positioning in 3D space relative to parent Nodes, although those
<img>
DOMElements shouldn't be nested in their DOM representation (useNesting(false)
would be perfect here).