https://bugzilla.wikimedia.org/show_bug.cgi?id=54604
--- Comment #73 from Krinkle <[email protected]> --- (In reply to Bartosz Dziewoński from comment #54) > (In reply to Gabriel Wicke from comment #52) > > Do we have actual measurements that verify that this benefits total page > > view performance in practice? > > We don't. Jon provided some funky tool in comment 11 but I've been unable to > get it to work. Krinkle provided a theoretical explanation on why this > should make a difference in comment 10. The performance impact is quite negligible actually. I'd rather let browsers worry about that. This shouldn't be a main driving factor in this case because it is too insignificant. My main point there was maintenance overhead: (Citing comment #10 from Krinkle) > * Hardcodes details that (other) stylesheets should not have to know or > hardcode, thus causing maintenance issues (e.g. the fact that it is an <a>, > and is inside #bodyContent. The container can change, and links might be > wrapped for presentational reasons) This would be mitigated by using a selector like: .mw-body-content a[href^="https://";] {} This doesn't have the added weight of an ID selector (#bodyContent) and is quite minimal and straight forward. (In reply to Gabriel Wicke from comment #62) > (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? That is indeed an important one to remember. Let's make sure we're compatible with that. (In reply to Gabriel Wicke from comment #69) > One issue I didn't mention yet is editor complexity. Every editor for our > HTML including VE will need to replicate the class logic from the parser. > This includes future micro-contribution tools like 'fix this link'. It seems > likely that this will lead to rendering inconsistencies when the logic > replication is not perfect. I agree. Adding all these classes to the Parser will inflate Parser output with information that can trivially be derived from the href attribute, doesn't really provide value to customers of the HTML (other than saving a few characters in stylesheet), and adds more or less random complexity to other producers of HTML such as VisualEditor content editable preview nodes and Parsoid. All the information about the url is right in the href. I think keeping classes like these out of page HTML would be optimal for maintenance overall: * Avoid imposing requirements on VE and Parsoid to add arbitrary attributes that the applied stylesheets should maintain instead. Separating responsibility and concerns; Unless it's a huge performance penalty we really shouldn't consider adding hooks like these inside the Parser for the skins' convenience. * Avoid optimising arbitrarily for the needs of one skin (the classes we add would only be for certain protocols and include certain file extensions in the media types. If another consumer doesn't agree with our grouping or wants more, they'd be back to square one in using href-matching; ergo, the approach doesn't scale and signifies that it'd wrongly divide responsibility between parser and stylesheet. I'd recommend going with something like: .mw-body-content .external[href^="https://";] {} -- 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
