make design AWAP without CSS or HTML
I know there's a thought to deprecate/eliminate CSS (such as float:right) from inclusion syntax. I'd be sad about this, not because I desparately want to use CSS itself in inclusions, but because I want to control as much design as possible without resorting to editing *css. Hence this inquiry about other ways to handle this sort of thing...
floating should be done via wysiwyg editor (or, eventually, layout editor)
Thought it would be good to connect this to related tickets. It is probably right that we need to do this sort of thing in the wysiwyg editor, which is TinyMCE for Wagn until we do something else.
btw, I like "awap"
I removed the "easier HTML editing" tag because this Idea is explicitly about maximizing Wagneerability *without* touching HTML.
Right, but the solution suggests that it will be fixed in the long run by improving the editor, which seems directly related. I guess what I'm thinking is that we should gather all the tickets that relate to improving editing or replacing TinyMCE, and make sure they are connected sensibly.
I agree that this ticket is more about inclusion syntax, i.e. having css things as inclusion options. Our main take-away is that AWAP is more important than a nebulous goal of keeping inclusion "css pure".
Implementation in the editor is a secondary issue, as either way we have to keep and extend inclusion syntax for AWAP reasons.
In general, I think using tickets as tags is not a great idea, it makes cards like Tickets by tag by name very noisy. At some point we realized that we wanted to see relevant support tickets from any given dev ticket, and the solution we came up with was on the support ticket to link to the ticket in the discussion. Then we added an inclusion on dev tickets that finds and links to the support tickets (discussed in support tickets+*right+*structure)). If we want to make more linkages among tickets, how about expanding on that approach?
This Idea is really more of a principle than a particular problem to be fixed. We could add it to wagn design principles...
+discussed in support tickets
+relevant user stories