2012/6/28 Jon Robson jdlrobson@gmail.com:
# "things rely on those inline styles whether we like it or not." No... They rely on styles not //inline// styles. This is my main problem with the current setup! I believe the majority of things done in inline styles that are essential would be better done in MediaWiki:Common.css - if we have text that is red this would be better down with a class markedRed otherwise some text risks being red or and other text #BE3B3B despite meaning the same thing. Most layout problems on mobile can be fixed with media queries. You can't do these in inline styles.
This makes no sense. Are you suggesting we create CSS classes markedX for every one of the approx. 150 color names accepted by browsers, as well as for every possible capitalization of these names? Because that's what we should do to avoid having "markedRed" word but "markedPurple" not for no user-visible reason.
(And I didn't even start to mention how this makes even less sense semantically than inline styles. What if one text is marked with "markedRed" and other is marked the same way despite meaning *different* things?)
What would sort of make sense would be classes like "wrong", "no" or "decrease", which would all have the same red color, but would mean different things. But now we're heading for unnecessary obstacles to editors...
-- Matma Rex