https://bugzilla.wikimedia.org/show_bug.cgi?id=24500
--- Comment #7 from Roan Kattouw <[email protected]> 2010-07-23 11:04:39 UTC --- (In reply to comment #6) > Special pages have also empty "Actions" and "Views". > > Why should user using agent without CSS see things he doesn't need to see at > all? Didn't we want to simplify things? Why do we out of sudden return useless > things we never used to return? > Yes, but there are scripts manipulating these portlets as explained previously. > We should care about the validity first. If something isn't valid, it makes > more difficult to convert it or its displaying might be rejected. Don't think > only about "all browsers you know" - there are not only browsers, there are > also random other tools, which rely or depend on validity. > I have a very very hard time imagining how a browser could possibly choke on an empty <ul> in any way, shape or form. It makes zero sense for a browser implementor to specifically enforce this requirement, because being tolerant is easier, and programmers are lazy. In general, yes, I agree that validity is important, but I believe we can make exceptions for such utterly brain-dead things as requiring (not saying "you shouldn't do this" but saying "you MUST NOT do this, validation will FAIL if you do this") that <ul>s not be empty. HTML5 has realized this and has removed this requirement. > We should also care about optimalization - why should user load unnecessary > and > useless data, which are hidden and won't be used? Not everybody is sitting in > USA on optical cable, you know? Lot of people still pay a lot per kB, not > small > monthly flat fees. > One empty portlet takes 158 bytes (before gzip). By contrast, the HTML of the enwiki main page is 57,629 bytes (before gzip, in Vector; Monobook is 406 bytes shorter). There are bigger fish to fry here, such as the many <link rel="stylesheet" href="veryLongURLHere"> tags, <script src="foo"> tags and the <script> tag with the huge pile of JS vars (the resource loader will address at least the first two). > The client scripts are the last piece in chain of website design, not the > first. We can not build the house from the roof. Fix the scripts then, if they > get broken by missing portlet. That is the proper solution. Not messing the > HTML. The scripts are supposed to accomodate to HTML not HTML to scripts. "Just fix the scripts" isn't that easy where e.g. user and site scripts are involved. IMO this is too much hassle for rather minimal gain, as most pages don't have empty namespaces or cactions portlets anyway. I do agree with removing the variants portlet if the content language has no variant support, because in that case it's quite clear you will never need the variants portlet anywhere on the entire wiki. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
