https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #62 from Gabriel Wicke <[email protected]> --- (In reply to Jon from comment #59) > Another reason is styles written in this way are not reusable. > > What if we want to use the same audio icon elsewhere? > > With an icon-audio selector class we can. > With a selector based on href we can't. This seems to overstate the case a bit. There's nothing stopping us from adding a selector in the CSS, and I don't see why that's more complex than adding the class in HTML. > 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. All these decision are engineering trade-offs, not implementation restrictions. If there are good engineering reasons (performance and CSS sanity for example) for generally adding more classes in the DOM & dumbing down the CSS selectors, then I'd be all for it. So far our strongest performance data seems to be page sizes, as that's easy to measure. Quantitative data on the relative importance of selector performance on total page render time is missing so far. My anecdotal evidence is that it wasn't noticeable when I added external link icons in 2004, on a laptop that would be considered a feature phone these days. (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? (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. > 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. -- 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
