in reply to PM CSS and markup optimizations
Some people like comments. I, for one, find them interesting. Others may be interested in how PerlMonks has the HTML structured, and they don't feel like running it though a beautifier every time. After all, we want to encourage learning, and not push away those who are curious, right?
Sure, it would save bandwidth. I don't know how much the server costs for PM, but if it's one of those "unlimited" plans, then it would be rather useless. Again, we seem to have gotten along just fine with how it is now, so there is no real reason for change.
I understand that some users have bandwidth restrictions on their end, so perhaps it could be enabled as a setting. That would probably be the best idea.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re^2: PM CSS and markup optimizations
by kimmel (Scribe) on Jul 12, 2012 at 21:13 UTC | |
Have you looked at the comments in a PM page? Here are all the comments from the landing page: That is 168 lines, 3,932 bytes of data sent per page load, less for pages with less content. What does that tell us? There is:
That reads like a list of debug statements. It is not a good practice to emit debug statements in production software. Commented out code should never stay around, we have version control for tracking changes. In addition, these comments provide no direct value to the general users of PM. Users are here to ask/answer/learn about Perl not focus on the markup for the content that was delivered to them. There are sites specifically designed for that purpose like CSS Zen Garden. Sure, it would save bandwidth. I don't know how much the server costs for PM, but if it's one of those "unlimited" plans, then it would be rather useless. Again, we seem to have gotten along just fine with how it is now, so there is no real reason for change.So saving bandwidth is good but we should not do it because PM does not need to change. Right. Delivering a smaller HTML page and CSS files makes the PM experience better. Faster page loads always make users happy and slower pages make users look for alternatives. I understand that some users have bandwidth restrictions on their end, so perhaps it could be enabled as a setting. That would probably be the best idea.This suggestion is not the "best" idea. It would require changes to the server software for processing each page on a per user basis. A simpler solution is just to take snapshots of a few pages, do a writeup and include those pages with the writeup on PM itself which is much easier work then editing the server software to add new features. Users can still study how PM works without sending data that is meaningless to most to all users. And then there is this statement: After all, we want to encourage learning, and not push away those who are curious, right?A flippant statement to prop up a strawman argument. Making statements like this just makes you look bad, point of fact. | [reply] [d/l] |
by thomas895 (Deacon) on Jul 12, 2012 at 21:47 UTC | |
That reads like a list of debug statements. It is not a good practice to emit debug statements in production software.And yet, everybody does it. Our good friends in PHP-land have plenty of well-known applications that emit debug statements in many places, as well. Of course, they are PHP users, and PHP people have a rather narrow mindset(but that is a different story), so that might be acceptable to them.
Users are here to ask/answer/learn about Perl not focus on the markup for the content that was delivered to them.Notice how you basically ruined the foundation of your suggestion? By the way, did you know that you could also shorten the class names on the elements using them? For example, instead of .pmsig, we could make it .pms. Oh, we would save so many kilobytes on long threads!
~Thomas~ confess( "I offer no guarantees on my code." ); | [reply] [d/l] [select] |