- From: Bruce B. Anderson <notifications@github.com>
- Date: Thu, 22 Feb 2024 09:08:57 -0800
- To: WICG/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <WICG/webcomponents/issues/1035/1959890110@github.com>
@matthewp, I was hoping to come back with a triumphant "first came the style attribute, then came the class attribute", but it appears my memory doesn't match up with what happened, and they were both released within the same year (at least). That's how I've always looked at this question. We need the style property defined locally on the element, before we can even talk about applying that style from a distance. When I think about binding, I tend to think in terms of where more of the keyboard typing is involved, which is more like attributes. Libraries like Vue and Angular and Auralia actually stick to attributes even with for loops, the exception being when the stuff inside the for loop can't be nested inside a parent tag. I suppose it is possible to look at a non attribute based "for-each" block surrounding a fragment of html tags as the equivalent of the font tag, only in the sense that, unlike the style and class attributes, the font tag does wrap a bunch of stuff inside. But I think the argument against the font tag was more a desire to keep things simple, and the font tag's purpose seemed to be easier to manage with inline styles (mostly (or maybe not?) applied programmatically via the property rather than attribute) and css. But one could argue that many design libraries are in fact the equivalent of a font tag. "Use this tag and you get this look and feel with all the stuff inside". I'm perfectly okay with that, because it seems to solve a difficult problem effectively. On the server side, few if any technologies take the approach you (and half of me) is advocating, and I've not seen a whole lot of concern raised about tightly coupling binding syntax with the outputted HTML. Yes, you could argue that the reason they haven't, is that building the complex infrastructure needed to be able to do the kind of css matching that the browser supports would greatly increase the costs. But you raised the issue of isomorphism earlier. How would there be any chance of isomorphism with the 100% css like approach if no server technology (I'm sure there are some very small exceptions) follow the same approach? What the current approach on the table is basically saying to the server is "say, you know that binding syntax you are using to bind your objects to the html? Would you mind sharing some of that information with me?" Seems kind of isomorphic, doesn't it? -- Reply to this email directly or view it on GitHub: https://github.com/WICG/webcomponents/issues/1035#issuecomment-1959890110 You are receiving this because you are subscribed to this thread. Message ID: <WICG/webcomponents/issues/1035/1959890110@github.com>
Received on Thursday, 22 February 2024 17:09:02 UTC