-
Notifications
You must be signed in to change notification settings - Fork 0
Workaround for <table>{{ rows }}</table> case #2
Comments
That seems a bit like too much magic and can end up getting in the way. It also doesn't cover all use cases, what if |
2. rule seems to be certain indicator for these cases, no? Alternatives like |
Sure, but changing where the nodes go based on their value means that (in theory) certain substitutions will occur inside the table and others outside, which would be a nightmare to debug. |
But isn't that what HTML does already with content inside the table? |
Yes, but in DOM, if you get a reference to that node and replace it with another node, the node doesn't move back into the table depending on what you replaced it with. It stays outside. See also https://en.wikipedia.org/wiki/Principle_of_least_astonishment |
The case of changing from tabular content to non-tabular and back doesn't seem to be practical, rather theoretical purity, which is according to W3C comes last:
From practical point the same strategy is available: the position is chosen once content is available, and that position is kept for the rest of the template lifetime. Possible problem is if user needs to manipulate template before the content is available. That can be alleviated by the 1. rule, but yes, it's unclear how to handle some exceptions like:
Although for tables the order of children may not play role. |
Ah yeah, I remember citing the Priority of Constituencies in my youth. 😊 Nice idea in theory, in practice users and authors are not above implementors, because when they are, stuff doesn't get implemented so neither authors nor users can use it. Avoiding surprising, non-overridable heuristics is not theoretical purity though, it's in the interest of authors. It's the authors that would get confused when their nodes are moved around for no obvious reason. The principle of least surprise is a usability principle, and usable APIs serve primarily their users, i.e. the authors. Anyhow, we've both expressed our views on this heuristic quite extensively, it's time for some more input from other people, so I'm going to sit back and wait for that. |
I agree 💯 with the principle, but sorry for repeating myself
Polyfilling that case for the most practical scenarios is possible. I was hoping not to abandon elegant syntax only because it'd take time for parser implementation to bump up. Users are not above implementors, but the W3C is. This situation that implementors drive standard is no-win, considering WICG/webcomponents#624 too - right things just get declined, with no reason. |
I think Justin Fagnani’s first bullet on the linked issue was really underappreciated. I think it makes sense to use the syntax the parser currently calls “bogus comments” for this purpose, given that they are currently never conforming, and work well with tables. I don’t know if the regular comment syntax should be allowed to form parts too, but to avoid it, maybe a good approach could be to mark these special “bogus comments” in some way. Maybe a new Of course, the “bogus comment” approach doesn’t need the braces, just e.g. |
Ok, there are valid cases where it's impossible to guess where the field came from:
both give same result:
|
Worked around in fork, seems that |
The
<table>{{ rows }}</table>
parsing problem can be reasonably worked around. As mentioned in this comment:Reverting the parser mistake by these two heuristics wouldn't be wronger guess than the mistake of the parser itself. (placing
<tr>
/<thead>
/<tbody>
content before the empty table to the table vs placing text content in the table out).The text was updated successfully, but these errors were encountered: