View Source Affordance as a sustainable engineering principle #62
Comments
|
I thought more about this, there are like a ton of resources which talk about whitespace and readability or methods of reading source, so its hard to suggest a single URL but someone may have a better idea |
|
Also, in practical terms, Would suffice, but we should still add a footnote or reference possibly about this practice! |
|
The ability to view source (and maintain readability of source code for the next person who maintains it) is important, which is why it was noted briefly, though I agree that it could be expanded upon (though here's where things get sticky). As to where it should go it will require some thinking because with code-compaction (minification), it's largely an automated process and IDE's have the ability (natively or with extensions) to just add that whitespace back in based on the developers preference. As for simply reading the code, "View Source" is largely redundant as things like the shadow DOM and live state changes cannot be seen by it (it can only see static onLoad code), which is why Developer Tools are the best way to view code forensically within a browser - all browsers have them, and they ignore formatting, preferences, and rendering choices. This means that even if code is minified, DevTools won't see things any different, it would just show it's human friendly tree. There is the issue of code commenting, which you note above that gets eliminated through minification, however, as it serves no purpose to the end-user it's wasted data through the pipeline to them and will only slow the loading of a website, won't be seen by the visitor, and costs bandwidth which may harm those on a fixed data plan or those on slow connections and thereby including unnecessary components is not only bad for web performance, it's considered an anti-pattern. As you can see, with browsers ignoring formatting but having a very functional DevTools, and IDE's providing one-click restoration of files readability, the only tangible case left is code comments - and the only sustainable case for that is not for visitors but for coders sharing project work (unless you can think of another use-case?) - which is partially covered by 2.12. So I could put a SC in there about maintaining well formatted and commented deliverables while in the development stage. (Plus some links to the topic under discussion to cover this?) |
|
The Success Criteria has been added. |
Hello fellow contributors,
I wanted to pose a question about one of the guidelines: https://w3c.github.io/sustyweb/#minify-your-html-css-and-javascript
This brief statement seems to basically move past the value that viewing the source code can provide in relation to sustainability in favor of the reduced traffic over the wire because of minification. Reading this without much context one might not take much note at all of the ability to view source code as it is contained in parenthesis and view it as not important to sustainability.
However, there is some thinking that having viewable source code as part of your application can actually be an engineering principle in it's own right. Some call this the View Source Affordance principle and there are low impact scripts and frameworks which prioritize retaining readability as part of their design, with the idea that people can reuse code and avoid wasted effort. In this way, it seems related to sustainability.
Is it possible we could add a sentence or two about the view source affordance concept, or a resource which explores that? There seems like there could be room here just for a tooltip about the value of reading source code 👍
Thank you for considering this idea and suggestion, possibly could be split into a different topic or area if its not quite an addition to this guideline. Or just kept as a reference issue in case the the issue comes up in future.
The text was updated successfully, but these errors were encountered: