https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #63 from Daniel Friesen <[email protected]> --- (In reply to Gabriel Wicke from comment #62) > > I'd like to see us moving away from descendant selectors and explore OOCSS > > [1] as a solution to our CSS mess we have created. We really should be > > making better uses of classes, and not be restricted by the implementation > > restrictions of Parsoid. > > I don't have a strong opinion on what's done in skins. My interest is > restricted to the content area. In general, we are currently moving away > from any skin- and pref- specific HTML (including classes) in the page > content. Our goal is to speed up page views for editors to the level of > current anonymous views. This means that any variation in rendering between > skins should be implemented in CSS only, and should not rely on different > classes being set depending on skin or user preferences. The suggested link classes are universal, they are not skin or user specific they are always in the dom dependent on what is in the dom. > (In reply to Daniel Friesen from comment #61) > > What if we "don't" want an icon? > > The .plainlinks class was normally used to mark this up, and applied to all > links inside a content block. How does this work with classes on each link? .plainlinks will continue to work for content, in fact it'll work even better since classes have less specificity than attribute selectors. But I'm not talking about content, but rather code. Adding links to elements or parts of the skin that happen to be under the root the link styles are defined on. With classes all an extension has to do is not use a link class. It can also add that link class to links that wouldn't normally match the selector (an extension could decide to link to a PDF reader with a document link style even though the url wouldn't have matched a .pdf$ selector. And to top that off by using classes instead of attribute selectors we can drop the root (#content / #bodyContent / .mw-body) since interface links won't be ruined by them anymore, and code can opt-in to link styles outside of content. > (In reply to Daniel Friesen from comment #60) > > Are the byte sizes of a few link classes really a big deal for actions as > > infrequent as a save? > > Page size is a big deal for uncompressed uploads, as upload speeds are > normally much slower than download speeds. Uploading a large article like > [[San Francisco]] from a DSL connection in San Francisco takes many seconds > (23 with current inline Parsoid metadata, around 7 without it), so a change > of 5% in the page size does have a measurable impact on save times, even on > a relatively fast connection. Things are worse than that when you are on a > bad connection in India. Which brings me to my other point: "Also I thought delta based saves were being done which make small byte size differences moot." So in theory changing %5 of [[San Francisco]] should not involve uploading all of San Francisco. Unless VE is implemented really inefficiently, tiny additions like link classes shouldn't have as much effect on small edits. And if it is implemented that inefficiently, we have a larger problem than the bytes add to link classes. > > If they are, isn't there any serverside sanitization of the DOM? These are > > internally generated classes, so if it were an issue couldn't you just strip > > them before transmission and let the sanitizer or parsoid generate the > > classes? > > We are working towards using Parsoid HTML for both views and editing, so > that you don't even loading a new page when switching to VE. Not relevant, my suggestion is that if you want size reduction on upload, then you could strip the link classes right before upload (which are automatically generated based on a set of rules) since and the server-side sanitizer (which should exist anyways to prevent the rules of the parser being intentionally screwed with or broken by an old VE version) would add them back. The parsoid output and view content (which are compressed and delivered by the faster download bandwidth) would still have the classes. -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
