In today’s web development it is common to build reusable components (the exact technology matters little) that may accept arbitrary children or parents. This means that the element used to implement this component needs to be as neutral as possible. For this, span is typically preferred. It would be possible to use div but it has downsides, notably its default block styling and the fact that it will close p if the tree is serialised to HTML.
The only downside to span is that it is considered an error as per Restrictions on content models and on attribute values. While it works perfectly well, developers are then dismayed to find out that the validator disagrees with them. Here is the example that prompted this post but it is not at all the only one, I’ve seen this complaint crop up several times over the past month. It’s a shame to get developers to fix something that’s not a problem.
This rule is meant “to avoid misuse of elements with defined meanings” but span “doesn’t mean anything on its own” and simply represents its children.
I would therefore suggest changing span's content model to take flow content instead of phrasing content.
I think a community discussion is essential for this question.
But the community are welcome, and encouraged, to discuss issues in the Working Group. Having them on github is meant to facilitate that.
If something clearly needs a lot of effort, e.g. because it has no implementation, or doesn’t have a proper specification, then it will almost certainly be marked as “needing incubation”. But where it’s a case of deciding whether to make a spec change that has implementation experience, I’d generally recommend raising the issue - although of course discussion elsewhere, including here, is also reasonable.
In other words, make the SPAN a more generic container that could be used as both SPAN and DIV.
Indeed, this works at least in Firefox, Chrome, IE11, and Edge: SPAN can contain block-level elements like P and DIV, and that’s not affected by browser’s HTML-error-correction mechanism. (But otherwise we could just introduce a new generic element instead of reusing SPAN, so there is a solution anyway.)
Regarding your linked example (the react-typewritter discussion), I’m not sure I understand how changing <span>’s content model would fix their issue. They want to be able to nest <p>s inside their component, but at the same time, they want to be able to have any element as parent.
But that is impossible! If a component nests <p>s, then it itself cannot be nested in, say, a <p> or a <h1> element. Instead, it must be nested in an element like <div> or <section>. This issue it unrelated to whether a <div> or <span> is used as a basis for the component, I think.
To clarify, for the use case of having a neutral element as a basis for a component, neither <span> nor <div> can satisfy all requirements, and the only workaround I can think of is to use the Shadow DOM. And since Shadow DOM currently isn’t widely supported, component authors have to define limits, e.g. if they want their component to be able to have any parent, they just cannot nest <p>s or other block elements.
I have not noticed any issue with screen readers. <span> elements are typically not included in the accessibility tree. I always thought that the span error was a parser constraint? If parsers don’t do anything weird, then it should be fine.
@robin Developers would like to avoid validation errors, yes. But the main question is, “are they misusing the <span> element?” To answer that, we need good use cases, which demonstrate that nesting block-level elements in <span> can be a valid pattern.
The provided example needs clarification; it is not clear what exactly they are trying to achieve. Their intent seems to be using <span> as a basis for an inline-block component. Does that sound right?
I read the topic and still I don’t catch the issue causing it, but that’s probably because I didn’t look thoroughly enough at the original example.
What I understand is that you need a span generic element because its parent element can be everything.
This means that you are not going to redefine the content model for span only. Because if you have a tree like this
then you are going to state that, with enough nesting depth, anything can contain anything. Which subverts the content model concept itself, at least when it comes to more generic situations.
I think the error is in the fact that you have too little control over the outer container. If you had a div generic container and forced its content to have at least a p element, everything could work in a more consistent way IMHO.
div […] has downsides, notably its default block styling
This downside can be solved by CSS I suppose, at least if IE<7 Support is not your primary concern.
My understanding as a lay person was that DIV and span did very different things.
DIV was for all intents and purposes block level layout. (equivalent to sectional/paragraph formatting on a word processor)
SPAN was for inline-formatting ( typically the character formatting options on a word processor.)
Having something that was an intermediate, might be useful, but isn’t that what a DIV with inline block is for?
(Aside: HTML currently seems to lack the ability to flow around an arbitrary block in the way that some Desktop publishing programs can. Granted this isn’t a major issue given the direction mobile content is going -> i.e flexible.)