Talk:Responsive web design

Wiki Education Foundation-supported course assignment

This article is or was the subject of a Wiki Education Foundation-supported course assignment. Further details are available on the course page. Student editor(s): Dmvhustler. Peer reviewers: Dmvhustler.

Above undated message substituted from Template:Dashboard.wikiedu.org assignment by PrimeBOT (talk) 03:05, 18 January 2022 (UTC)

Proposal to integrate content from several articles

I just proposed reorganizing content from this and other articles into a more general page, perhaps titled "Web Page Layout". Please check out Talk:Tableless_web_design#Proposal:_Integrate_other_page_content, and comment there. Davidlark (talk) 02:46, 8 September 2017 (UTC)

Photo of Marcotte

In response to LittleBenW deleting the photo that I posted, with the comment that a photo of Marcotte belongs on a Marcotte article and not on the responsive web design article: I will point out that the theory of relativity article has a picture of Albert Einstein, and the gravity article has a picture of Sir Isaac Newton. If those pictures are appropriate on those articles, then a picture of Marcotte on the responsive web design article is certainly appropriate. Clarissa Peterson (talk) 03:43, 26 August 2012 (UTC)

• I can't see a picture of Albert Einstein in the theory of relativity article, though there is a picture of a Russian postage stamp issued to honor him. Has a stamp to honor Marcotte been released?
• Sir Isaac Newton and Nobel-prize-winning Albert Einstein are in a completely different league as to notability. The term AJAX was coined by Jesse James Garrett in 2005, but that does not make him notable enough to add his photo to the AJAX article—and adding his photo to the AJAX article would not improve anybody's understanding of AJAX. RWD is even newer than AJAX. Notability takes longer than that. Coining a name for something that already exists is not as notable as creating a genre from zero. Even creating a genre from zero (as, for example, DJ Kool Herc is credited with doing for Hip hop) does not earn a photo on the Hip hop page.
• Feel free to propose a Marcotte page if you wish. But maybe such a photo would not add useful information even to a Marcotte page, if there were one—his face is too small to be recognizable. LittleBen (talk) 04:07, 26 August 2012 (UTC)
• I have made the point that the photo does not add any information to Wikipedia users' understanding of RWD, the face is too small to be recognizable, and that you are free to create an article on him and add his photo to that. LittleBen (talk) 04:37, 26 August 2012 (UTC)

Regarding your note that I am free to create an article on Marcotte: I do not intend to do so. I am not very experienced on Wikipedia, and do not feel confident in my judgement as to whether a subject would meet the standard for notability. Clarissa Peterson (talk) 05:12, 26 August 2012 (UTC)

• If an article on Marcotte would not meet the standard for notability, then a photo (which does not even show his face clearly) would not make the cut. Wikipedia is not a fan club. You can get help with creating an article (on Marcotte); you can create an article in the sandbox area of your user page, and ask for advice and help from experienced editors. I will ask for a third opinion. I can't see any connection between Responsive Web Design and "Robot Monster", which is about all that is visible in the picture. His tiny book on RWD is currently ranked #223,168 on Amazon, way below other books on the topic.
• Your breaking the article into sections does improve the article. LittleBen (talk) 06:54, 26 August 2012 (UTC)

Thank you for offering the links for help with creating an article page. However, I prefer to limit my involvement at this time to making edits rather than creating pages, until I am more experienced with Wikipedia. You may notice that many newer editors do the same. Thank you also for being willing to ask for a third opinion.

• There are no photos of the people who named the strategies "Mobile first", "Progressive enhancement" or "Unobtrusive Javascript" some ten years ago, so I don't think it's appropriate to add photos of individuals related to RWD either. The WP:3O page is currently broken, so I'll get a third opinion when it's fixed. Other books on RWD are surely 250 or 500 pages long, not 140 pages. LittleBen (talk) 07:25, 26 August 2012 (UTC)

The book that comes up first when I search for "responsive design" on Amazon is Responsive Web Site Design, Quick Guide How To Get Your Site Ready For Every Device And Browser and it is listed as 50 pages. The one after that is 324 pages. The Smashing book is only 150. Not every book is long, and not every long book is good. Having read Marcotte's book, I think I would describe it as concise, rather than "tiny." Clarissa Peterson (talk) 07:47, 26 August 2012 (UTC)

• Both Frain and Kadlic books are similarly priced, but double the size. The Gillenwater "Stunning CSS3" book, dated 2010, is even more substantial. LittleBen (talk) 07:57, 26 August 2012 (UTC)

Response to third opinion request:

As the images on Wikipedia serve the illustration purposes, I see no point in the article that may be illustrated by the photograph of any person. Furthermore, the photograph creates a undue weight issue, as it overly emphasizes the role of Ethan Marcotte (who merely named the concept), while more weight should be given to the technical point of article. If illustration is deemed necessary, a map image (or video of resizing browser window) would be ways more appropriate here.— Dmitrij D. Czarkoff (talk) 09:47, 26 August 2012 (UTC)

Changes to Content of Article

You added: "This is in contrast to other approaches which call for the creation of ... separate designs for various screen sizes". In fact RWD calls for separate designs for different screen widths, so this is factually wrong. For this reason, RWD is more expensive than a simple design without media queries. LittleBen (talk) 08:06, 26 August 2012 (UTC)

I am going to change the wording to say

• RWD: "in which an adaptive design is crafted (using one set of code) to provide..."
• other approaches: "separate sites or designs with separate sets of code"

Feel free to change that wording on the page if you disagree.

You have not expressed any specific objections to the numerous other changes I made, so I'm going to put those back in. I have no problem with you making changes to anything I add or edit, but removing all of my edits at once is not appropriate. Even if you think some of it is wrong, there is certainly some of it which is not wrong. Clarissa Peterson (talk) 08:22, 26 August 2012 (UTC)

• If you look at "Page View statistics" on the history tab, you will see that this article has received 38274 page views in the past month—whereas Wikipedia:Manual of Style got only 35087 page views (and was ranked #3120 on Wikipedia). I think this is because the many people who visit this RWD page want to learn about the technology, and find useful references, not because they want to see pretty pictures of individuals and dumbed-down explanations that are technically wrong. At about the end of January, I asked for a stub article on RWD that had been deleted to be undeleted, I have greatly fleshed it out with useful material, and enough people seem to think that it is useful in its present form to have made it very popular.
• Adding section headings was an improvement, the photo is to get a third opinion, but reorganizing it and adding factual errors is not an improvement, sorry. LittleBen (talk) 08:25, 26 August 2012 (UTC)

Just because a lot of people visit the page doesn't mean that it was perfect and could not use any improvement.

I made a lot of additions that I think you will find are useful, like adding wikipedia links to several phrases that weren't linked before. There were also a few factual inaccuracies that I fixed. For example, the term was actually coined at An Event Apart, not in the subsequent article by Marcotte. Clarissa Peterson (talk) 08:31, 26 August 2012 (UTC)

• Quote: "I made a lot of additions that I think you will find are useful, like adding wikipedia links to several phrases that weren't linked before".

• Feel free to add links to Wikipedia articles that define terms.

• Quote: The term was actually coined at An Event Apart, not in the subsequent article by Marcotte.

• You should add dated references that justify any such claims.

• Do you know Marcotte personally? If so, be aware of WP:COI.
• People who view technical articles are more interested in learning the technology rather than the history, that's why I don't think changing the order is an improvement.
• RWD means using media queries to present different layouts to different devices. So saying that NOT having to prepare different designs for different devices is an advantage of RWD is completely wrong—it's the exact opposite. LittleBen (talk) 08:49, 26 August 2012 (UTC)

I do not know Marcotte personally. I do admire his work, and I've read his book and many of his articles.

As background, I have been a web designer/developer for 10 years, and have done a lot of responsive design. I also have recently taught a workshop on RWD and I have other speaking engagements coming up, so that shows that I am respected by my peers for my knowledge on the subject. I understand that considering myself knowledgeable in a subject doesn't give me any greater right to edit a page than anyone else, but it should at least tell you that I am not just randomly making things up to put on the page. I am simply trying to use my knowledge and experience to make the page better by improving the language and going into more detail about the different parts of RWD.

That said, I make mistakes like everybody else, and if you feel like I have made any errors in my edits to the article, please tell me what they are. But it is unfair to discount my opinions entirely.

Telling me where I should have added a reference is helpful, and I will do that. And I would appreciate any other specific direction as to what I can do better. Clarissa Peterson (talk) 09:05, 26 August 2012 (UTC)

I don't think we disagree on the process, I think we're just using different words to describe it. Clarissa Peterson (talk) 09:14, 26 August 2012 (UTC)

• My background is engineer/tech. writer, and translator—I have also taught IT and web (SEO, analytics, Internet research) related subjects. By adding the section headings you have shown that I am no good at graphic design ;-) But I think that the organization of the article is basically OK—it's primarily about what RWD is, not primarily about the history of the RWD name and Marcotte.
• I have already explained that most people want to quickly get to the technical essence rather than have to wade through photos and discussions about "popularity" first. That's surely why WP:MOS is not as popular—it's difficult to find what one is looking for.
• Eight layouts is eight different designs. The phrase "same code" is surely so vague as to be meaningless. LittleBen (talk) 09:33, 26 August 2012 (UTC)

I wouldn't think that everyone going to a page wants a technical description. I often look something up on Wikipedia when I hear an unfamiliar term on TV or in a book. If it's technical/scientific, I expect that the first paragraph will say what it is in words I can understand. I expect that the rest of the page might be beyond my understanding, but at least the first paragraph needs to be for everybody. People are curious about things, they don't want to know everything, they just want to know what it is. I think that's an important part of what Wikipedia does. You can find out what anything is.

If you know of statistics that show people are only looking for technical descriptions, I would be happy to be corrected. Clarissa Peterson (talk) 09:41, 26 August 2012 (UTC)

• You write, "Element sizes are expressed in percentages of EMs," but the head of the article (and the Marcotte article) say (relative units like) percentages or Ems". To a Tech. Writer, a mistake like that is awesome. LittleBen (talk) 10:04, 26 August 2012 (UTC)

Yes, that's a typo that I put "of" instead of "or". Thank you for proofreading. I would have caught it on the next read through. But sometimes a mistake is up on the page for a little bit. I already said I'm not perfect. Clarissa Peterson (talk) 10:12, 26 August 2012 (UTC)

Also, I think you're in a different country. It's the middle of the night where I am, or actually it's pretty much morning and I've been working on this all night instead of sleeping, so my brain is a little fried. But I want to get this resolved. I didn't think making edits would be such an issue or I never would have bothered. Clarissa Peterson (talk) 10:16, 26 August 2012 (UTC)

• Your definition of flexible images only presents Marcotte's viewpoint, and says nothing about techniques for resizing huge images designed for large-screen desktop PCs or Retina displays (or presenting alternative images) to suit dumb small-screen mobiles and low bandwidths (see ref. 9). This is perhaps the biggest obstacle to RWD, and Marcotte didn't solve it.
• People coming to this page want to see what RWD designs look like. So it is not appropriate to remove the link to representative RWD sites chosen by Marcotte.
• A third opinion—that an image is not appropriate—has been added above. Do you want to appeal this further?

• Quote: "I think you're in a different country. It's the middle of the night where I am, or actually it's pretty much morning and I've been working on this all night instead of sleeping, so my brain is a little fried. But I want to get this resolved. I didn't think making edits would be such an issue or I never would have bothered".
• Your health should come first, get some sleep. If you think that your editing sprint has taken a lot of time, then imagine the amount of time I have spent researching and polishing the article. Don't be discouraged. But it's better to do a little at a time—it makes it easier for other people to check—and discuss far-reaching changes on the talk page first. Because if there are too many radical changes that seem undesirable then it is simpler to revert them all. LittleBen (talk) 10:28, 26 August 2012 (UTC)

Before I saw the third opinion I had added an image at the top that shows the responsive Boston Globe site. I changed the image of Marcotte to one where he has CSS on the screen behind him, and moved it down the page, and it's a smaller thumbnail (like the original photo I chose). Are you okay with the Marcotte photo down the page and smaller, or do you still feel strongly that it should be removed?

I see your point about having a link to representative RWD sites, but the link you had on there was almost a year old. RWD has matured so much in the past year I don't think the list would still be representative. Can we try to find a different list to use instead?

I feel like the order of the three elements should have media queries last, because you have to implement it in that order. I have never seen it described in any other order. Do you have a reason for choosing the order you did? Clarissa Peterson (talk) 10:52, 26 August 2012 (UTC)

• I'll fix your Multiple references to the same footnote. You should get some sleep. Feel free to find other lists of responsive sites——I think .net mag. has some every month, but possibly they're not on the website.

• Quote: I feel like the order of the three elements should have media queries last, because you have to implement it in that order. I have never seen it described in any other order. Do you have a reason for choosing the order you did?

• As I said, consistency: that's the order in which it's described at the top of the article.
• Time-sequence-of-events (or actions) is one criteria that tech. writers use to put stuff in a logical order: the browser runs the media query first to choose the appropriate layout. HTH (Hope This Helps). LittleBen (talk) 11:07, 26 August 2012 (UTC)

• I don't think a photo is appropriate. Otherwise every new amateur band and fashion label would want to have photos of their members or directors advertised on Wikipedia. Wikipedia is more about enriching everybody by sharing ideas than promoting individuals' agendas. A photo on the page of a really notable individual is different. LittleBen (talk) 11:47, 26 August 2012 (UTC)

I would note that image from this edit is a perfect illustration, though I would suggest to make thumbnail larger, so that the the screen content may be identified as the same page without following the link. — Dmitrij D. Czarkoff (talk) 11:23, 26 August 2012 (UTC)

• Thanks for giving a 3rd opinion. We seem to agree that photos of individuals, however small, don't belong. I'd personally rather see a list of representative sites that demonstrate what RWD is, rather than a thumbnail of a single RWD site (which I think Marcotte may have been involved with). A link to the Boston Globe site ("see RWD for yourself") would also seem more helpful to me than a link to the Wikipedia article on the Boston Globe. LittleBen (talk) 11:47, 26 August 2012 (UTC)
  • I'm pretty sure that linking to Boston Globe would be a bit excessive per WP:ELNO #13 and WP:EXAMPLEFARM. Image showing single site on different devices (specifically including older devices, Apple Newton in this case) helps to understand the concept; the link to any RWD-enabled site helps ways less, as most readers would see the site from a single device, and I doubt that they would experiment with resizing the browser window to see the effect. — Dmitrij D. Czarkoff (talk) 12:00, 26 August 2012 (UTC)
• Thanks again for your comments. LittleBen (talk) 12:09, 26 August 2012 (UTC)

I've added a link to a list of responsive site examples from 2012. Is putting it under external links the most appropriate way to do it? Now that there's a recent list, is it okay to take out the 2011 list?

I know I didn't say anything retina images, but neither did you. Marcotte didn't address retina images in his definition of responsive design originally, because at that point in time Apple had not yet come out with the retina displays. So that's an area where everybody has been playing catch-up. There is not consensus on a solution yet; there are multiple avenues to address the issue. I can write something up about retina eventually, unless you want to do it. I think the RWD page could easily have 5x as much information if we hit on all the different issues. Another area that needs to be discussed is responsive workflow. Clarissa Peterson (talk) 12:17, 26 August 2012 (UTC)

I strongly feel that the bulleted list format is the best way to display the list to increase readability and comprehension, since they are multi-sentence definitions. Clarissa Peterson (talk) 12:24, 26 August 2012 (UTC)

• Quote: Is it okay to take out the 2011 list? I strongly feel that the bulleted list format is the best way to display the ("Elements") list.

• I like the 2011 list because it shows both small-screen and big-screen views so is more intuitive (as per 3O reviewer's comment). It's a fact that the sites were chosen by Marcotte, and this was published less than a year ago, so I think that it should stay in the history section. Other "examples of RWD" sites (other than the one you added) also show both small-screen and big-screen views.
• I like the bulleted list format too, but am not sure if it's used much in intros. I feel that the ”As a result” in the intro. is important.
• As mentioned above, one way of avoiding the serving of large (desktop-sized or retina-sized) image files to dumb mobiles over low-bandwidth connections is covered in ref. 10. LittleBen (talk) 12:44, 26 August 2012 (UTC)
• Funnily enough, one very popular tech. page on Wikipedia is HTTP 404. People are surely trying to find out the meaning of this technical term, rather than looking for the picture and history of who invented the term. ;-) LittleBen (talk) 13:21, 26 August 2012 (UTC)

• A brief and simple page (like the present RWD page) where everything is "above the fold" and one can find answers quickly is surely preferable to a humongous page which takes ages to read (if you have the patience), and requires reams of paper to print out (like MoS).
• The Web design article gets a lot of page views (popular keyword) but is poorly written. I've touched up a few pieces of it, but it's too long and rambling for me. I think it covers work flow, or has links to articles that talk about it. LittleBen (talk) 13:29, 26 August 2012 (UTC)

"Brief and simple" is not always preferable; it really depends on the communication goals of the page. If you have a lot of information to convey, a long page may be necessary. It's not expected that everybody will read the whole page. The key to making your page successful is to have a straightforward introduction section that can stand alone for those people who do not desire additional information, followed by a table of contents that reflects a well-planned document structure using accurate and descriptive headings. Many times I have visited an incredibly long page on Wikipedia to find a specific piece of information, and yet had no trouble getting to the right place via the table of contents. That is preferable to a brief and simple page that may have omitted the information I was looking for in order to save space. Clarissa Peterson (talk) 22:17, 27 August 2012 (UTC)

• Jakob Nielsen coined the phrase above the fold. He discovered that the majority of web users take only about 15 sec.—looking at only what is visible on screen (without scrolling) [this is what he means by "above the fold"]—to decide whether a site or page is relevant to what they are searching for, or not. You can easily measure this (time to bounce) using Google Analytics or the like. That's why several short and simple focused pages on different topics can be much more effective for SEO than a single humongous page that tries to cram in every topic under the sun, and include everything but the kitchen sink. LittleBen (talk) 03:02, 28 August 2012 (UTC)

What you are saying about above the fold is not a contradiction to what I'm saying. Nielsen said that users spend 80% of their time looking at material above the fold: Scrolling and Attention. That is a lot, but there is still 20% of the time they are looking at information below the fold, which is not an insubstantial number. That's why it makes sense that the most important content is at the top of the page, yet the page can have additional information further down that users can easily navigate to via the table of contents. The users who want more in-depth information are the ones spending the extra 20% of time.

Also, the goal of writing and editing content on Wikipedia pages is not to increase SEO, it's to provide comprehensive information on a topic. So I think that for Wikipedia, UX guidelines should be given greater weight than SEO guidelines, when considering how to organize content on a page. Clarissa Peterson (talk) 20:53, 28 August 2012 (UTC)

• Quote: What you are saying about above the fold is not a contradiction to what I'm saying.
• What I said was that most people look only above the fold, and only for about 15 sec., in deciding whether to stay or move on. If you use analytics, you will find that 50-70% of people who visit a web page bounce within about 15 sec.—they do not stick around to look at what is below the fold. The nice picture (like you added at the top)—and the subheadings that were your idea—will surely result in more pageviews and probably also more people reading more of the page, though Wikipedia doesn't seem to have "average time on page" (or %bounce) stats. that analytics would give. As you can see, pageviews are up from a peak of over 1,750 to a peak of over 2,000—so I think the eye candy made a difference. I might do some work on the humongous "Progressive Enhancement" article, which has a lot of out-of-date stuff, and really deserves better. Supporting "tapping" rather than just "clicking"—and adding "hover" effects for desktops that support it—are forms of progressive enhancement. But I'm swamped with other stuff at the moment, so it may have to wait a while. LittleBen (talk) 03:10, 29 August 2012 (UTC)
• Quote: the goal of writing and editing content on Wikipedia pages is not to increase SEO.
• I have answered that at Wikipedia talk:Article titles#Google Insights. I'd summarize my reply to "SEO is irrelevant" as, "if people don't read what you've written, then you've wasted your time writing it". Improving the user experience, improving the writing and focus of the content, and making it easy to see an overview of the contents "above the fold" are likely to greatly improve SEO.
• PS: If you don't mind, I'll abbreviate some of the top of the talk page by commenting it out in the HTML. Nothing will be changed, it will just not be visible to the average user. The talk page is getting so long as to be intimidating. LittleBen (talk) 03:48, 29 August 2012 (UTC)

I fleshed out the info on responsive advertising to go into more detail. You may have additional viewpoints to add. I am going to try to add to other sections of the page when I have time.

It's okay with me if you comment out some of the talk page. I don't know how that is usually done, is there a note that content has been removed so that people can know it's there?

I wasn't saying that SEO is irrelevent. I was saying that for Wikipedia, writing good and useful information should be higher priority than following SEO guidelines that may be contrary to user experience guidelines. Again, I don't think we disagree. This page is already one of the top results in Google for "responsive design" so I don't think it's necessary to put a lot of effort into optimizing for search engines. Good user experience frequently results in good search engine placement. Clarissa Peterson (talk) 20:09, 29 August 2012 (UTC)

• You can see in the HTML which parts of this talk page are commented out (much of the very long discussion on the Marcotte image) via the History tab.
• You added far too much detail about ad pricing models, copied from the references. It's better just to link to detailed, off-tangent articles, and let people check them out if they are interested—rather than force people to wade through a lot of detail that is about advertisements rather than RWD (most of the article is theorizing about how ads might be handled in future). I think I have seen a Google developer article on ads and RWD; will try to find it and add it in.
• Wow, 50% jump to 2,500 pageviews. LittleBen (talk) 03:42, 30 August 2012 (UTC)

Little Ben is clearly trying to be manipulative. This is not Reality TV, so "ratings" are not what we are after. Also suspect that he (or his buddies) are playing around here. This whole article reads like an ad for a couple of book authors and some dubious blobs of Javascript (e.g. jQuery, Modernizr). And this after he deleted my "talk". I suspect Little Ben works for this Marcotte guy's publisher.

It's clear that my changes *explain* the related concepts far better than plugs for jQuery and the like. And pixels are *not* absolute units. The revert-er of *that* change should have followed the link. Clearly accuracy had no impact on the revised ratings.

As the "third opinion" said, Little Ben needs to stop reverting my changes wholesale. This is not his own personal playground. — Preceding unsigned comment added by 75.186.15.4 (talk) 18:18, 21 September 2012 (UTC)

Edit warring

Respond if you must, but please do not delete discussion entries--was not unsigned either (see above). The bot signed it for me. Thanks!

As now explained twice, the section that you deleted is called "Related Concepts" and describes how Media query support (required for a RWD design) and maybe HTML5 support are tested for, and how support can be added (by "polyfills") to browsers that don't support them like IE8 (see Ref. 5). If you still can't understand this then you would be well advised to stop vandalizing the page, and revert-warring, or your IP will be blocked. LittleBen (talk) 10:04, 7 September 2012 (UTC)

I'm not "revert warring". I asked you to take it to the talk page. Now that you are here, see that I did your work for you by rewriting the paragraph to link to appropriate Wiki articles. You clearly do not understand topics like feature detection, feature testing, cross-browser scripting, browser detection, etc. and that topics like "polyfills" are too specific for the "related concept" section. Please leave that section to somebody who does.

And certainly the links to jQuery Mobile, etc. were out of place. Those are dubious JS libraries and have nothing specific to do with this topic. If you like, you can link to a general "Javascript Libraries" page.

If you continue to Spam this page with confused (and confusing) non-technical nonsense, then you will be banned. How do you like that? -David Mark 75.186.15.4 (talk) 14:28, 7 September 2012 (UTC)

I created this page essentially from nothing back at the end of January. You might like to look at the page ratings at the bottom of the page (which reflect the ratings before you started editing it). You might also like to look at the pageview statistics on the history page. It should be obvious that a lot of people do not consider the page to be rubbish. Your opinion that jQuery Mobile is a "dubious JS library" and that "polyfills" are too specific would not make any sense to anybody who is even slightly knowledgeable about the web. LittleBen (talk) 17:22, 7 September 2012 (UTC)

Your opinion that jQuery Mobile is a "dubious JS library" and that "polyfills" are too specific would not make any sense to anybody who is even slightly knowledgeable about the web.

This is simply false. jQuery Mobile is counterproductive to mobile development. This is evinced by its requirement for the jQuery library (250 kB+ unobfuscated) along with the jQuery Mobile library itself (230 kB+ unobfuscated). Sending 400 kB+ of script to a mobile device, let along a desktop device, is lunacy.

Polyfills are troubling as well because they are inherently naïve in design. They provide poor browser support as they rely on very specific host implementations; they are also often written sloppily, with a very limited subset of browsers in mind. Consequently they are unsuitable for reference, which David correctly pointed out.

As someone who has successfully written a comprehensive DOM library and can support dozens of browsers, I hereby rest my case. Mkmcdonald (talk) 20:18, 21 September 2012 (UTC)

WP:OWN still applies. If you don't want your additions edited, then get a blog instead. Andy Dingley (talk) 17:55, 7 September 2012 (UTC)

Response to third opinion request:

Hi. First off, nothing here could be considered vandalism or spam, so please stop throwing around unfounded accusations. I think there is room in the article for coverage of feature probing techniques, the use of libraries like jQuery, and the polyfil techniques that either approach might use. David/75.186.15.4, try to avoid editorializing against the use of libraries. There are advantages and disadvantages to each approach, neither one is "right" or "wrong". That said, I think most of the IP's additions have been constructive and have improved the article, so they should not be reverted. The bias against the use of libraries can be balanced by adding objective facts on the advantages and disadvantages, and very selectively editing statements of opinion. On an unrelated style note, section headers should be upper case first letter only, not every word. Hope this helps, and remember, focus on the content instead of making accusations.Gigs (talk) 18:10, 7 September 2012 (UTC)

His comment that jQuery Mobile is a "dubious JS library" shows that he has very little subject knowledge, yet he is making insulting comments like "Please leave that section to somebody who does", edit warring, and repeating threats like "If you continue to Spam this page with confused (and confusing) non-technical nonsense, then you will be banned". He surely needs educating that such behavior is not acceptable. LittleBen (talk) 18:20, 7 September 2012 (UTC)

It seems to me that you are both knowledgeable in this area. You both got off on the wrong foot, he called your content nonsense, you called his edits vandalism. Please try to get over the personal issues so that you can both concentrate on the content. Gigs (talk) 18:30, 7 September 2012 (UTC)

• Thanks. I'll try, but I don't think that he is capable of discussing it—I had to explain the basics to him a couple of times; he didn't understand. LittleBen (talk) 18:38, 7 September 2012 (UTC)

• Before all the rubbish was added to the page, the page ratings were Trustworthy: 3.5, Objective: 4.5, Complete: 4.0, Well written: 4.5
• The rambling rubbish that was added has caused the page ratings to plummet to Trustworthy: 3, Objective: 1.0, Complete: 4.0, Well written: 2.0   Wikipedia readers are obviously pretty knowledgeable ;-)
• Now that I've fixed the problems, let's see the ratings skyrocket (if he doesn't mess with it again). LittleBen (talk) 11:23, 11 September 2012 (UTC)

• Trustworthy: 5.0, Objective: 5.0, Complete: 5.0, Well written: 5.0, as of 19 Sept. Thank you, kind people! LittleBen (talk) 03:24, 20 September 2012 (UTC)

Nobody cares about your manipulations (see comments above). You bulk-reverted a lot of good information, simply because you either did not understand it (seems likely) or you are trying to treat this page like an infomercial. Anybody can massage "ratings" and then claim that they validate invalid opinions.

He appears to be at it again. I monitored the ratings for the first hour or so after adding my useful information back in to the article. About an hour later, it appears "Little Ben" noticed the changes as a tsunami of negative ratings poured in all at once. He'll try to use that "feedback" to "prove" that his edits are preferable (which is laughable as they don't say much of anything compared to mine). — Preceding unsigned comment added by 75.186.15.4 (talk) 20:50, 21 September 2012 (UTC)

I really think "Little Ben" is a disingenuous contributor. One thing is for sure, he doesn't know much of anything about Web design (responsive in particular). It's certainly not about downloading JS libraries. — Preceding unsigned comment added by 75.186.15.4 (talk) 18:22, 21 September 2012 (UTC)

Blanking and commenting out

Please don't blank or comment out sections on either this page, or in the article. Blanking, commenting or almost any editing (even trivial typo correction) of other's comment on a talk page is heavily frowned upon. There are very few cases when this is considered acceptable. If you search through the bucket o'policy, you'll find these discussed at length, but if you haven't, or can't, find those yet, just assume that you're not yet sufficiently familiar with WP arcana to have a hope of getting it right. Those editing others' talk page comments are likely to find their edits considered as vandalism, warned and then blocked. If in doubt, don't Please don't comment out sections in the article. If you think they should go, then delete them. MediaWiki acts as a version control system, so nothing is "lost" by doing so. It also makes the edit-by-edit diff display work correctly. Commenting instead confuses the diff, article size calculation, and other editors. Editing in a manner that might be seen as deliberately confusing or misleading to other editors is also frowned upon. Andy Dingley (talk) 16:19, 19 September 2012 (UTC) I haven't seem any guidelines on temporarily commenting out sections of articles, so would appreciate knowing where such guidelines are. Another user reorganized part of the body of the article, and essentially identical items ended up in two places. Cloning the better of the two, then editing and commenting out parts of one of them, was the easiest way to ensure that nothing good was lost. I converted the doubled-up reference citations to named references, commenting out as I went. I was rather surprised when somebody suggested that if a good article is trashed by a vandal, the author of the article should give up on Wikipedia and start a blog. Would you regard such a suggestion as constructive or useful? LittleBen (talk) 02:02, 20 September 2012 (UTC) Welcome to Wikipedia. You aren't likely to change it, so best learn how it operates. I've seen no vandalism to this article. Different opinions are not vandalism. Calling things on WP "vandalism" when they aren't will have you booted through the door in no time. Pointless? Maybe. But that's how it operates. Read WP:OWN. Get used to it, that's how it works here. If you can't work within that, then get a blog. You'll not last long railing against WP otherwise and how "everyone is doing it wrong". WP has crushed and spat out better editors that you or I before now. If you like, wear a hair shirt, eat locusts and go and sit on the naughty pillar with Peter Damian. What you won't do is to change the editing model at WP. Either work within it, work elsewhere, or be stomped flat by it. My comments immediately above though are just trivia. Don't fuck about with the changelogs, because the droids keep it tidier without having to work around comment delimiters. It's not a political point, just housekeeping. Andy Dingley (talk) 12:17, 20 September 2012 (UTC) As suggested here for off-topic posts and personal commentary, I added Template:Collapse. LittleBen (talk) 02:27, 21 September 2012 (UTC) I have also just found Wikipedia:Refactoring talk pages. LittleBen (talk) 01:22, 19 October 2012 (UTC)

Propagation of Misinformation

As someone who has seen misinformation, especially on Wikipedia, virally infect the Web/JavaScript community, I hereby urge any participating members to be wary of edits referencing third-party APIs as magic bullets. Responsive Web Design is perfectly easy to enable without third-party APIs. It has existed in the form of liquid layouts well before CSS 3 became abuzz. Also, the predilection towards name-dropping is worrisome. As I mentioned earlier, Responsive Web Design is a strategy that has evolved over the past decade or so. No one single human deserves credit for it: the community that fostered it does.

The History section appears to be one cohesive marketing pitch. I would scrap all of it, save for the first sentence. Commentary on how the technology existed long before the moniker was coined (as with AJAX) would be an adequate replacement. The current state, which borders on false attribution, is biased. Mkmcdonald (talk) 20:44, 21 September 2012 (UTC)

• I would disagree that Responsive Web Design is the same thing as liquid or fluid layouts. They have similar goals, but there are additional features in RWD that weren't available before. AIUI, the single, crucial difference is that RWD involves a server-based, or HTTP-based, selection of different transmitted content to the client. Fluid layout did not require this: fluid layouts instead used a single description of the styling, annotated this with a mix of absolute and relative units together with a specification for floating behaviour, then allowed the client's rendering engine to make its best attempt at it. Fluid layouts did specify a linear, logical order for content units (HTML documents are still serial files), but they no longer attempted to enforce a rigid two-dimensional grid of relative positions. Andy Dingley (talk) 09:28, 23 September 2012 (UTC)

It's not *just* liquid (AKA fluid) layouts, but that's one big part of it. According to the article (and ostensibly the book that it is based on), the other parts are "use EM's" (even for images, which doesn't make a lot of sense to me) and "use media queries" (which were predated by "handheld" media style sheets).

Finally, anything that requires the server to guess about client capabilities (e.g. to send different content to the client) is going to require browser sniffing (and on the server side to boot). That's nothing new (and certainly nothing good). If "RWD" recommends such strategies, it is yet another indication that it is a dubious amalgamation of extant techniques (both good and bad). There were "solutions" at the turn of the century that tried to send smaller images, black and white images, alternate scripts and style sheets, etc. to small screen devices by sniffing the optional and arbitrary UA header.

Further reading:

https://gist.github.com/3768460

And, contrary to Little Ben's opinion, I have a lot of experience in these matters. I use these techniques, but I don't write about them in blogs.

Notes

Pixels as absolute units

Opinions (and references) please. Append you comments, please don't edit or delete those of others. Andy Dingley (talk) 19:58, 22 September 2012 (UTC)

Somewhere in a vast section of unhelpful snarking below, LittleBenW posted the following source for pixels as being an absolute unit.

• "5.2. Absolute lengths: the 'cm', 'mm', 'in', 'pt', 'pc', 'px' units". CSS Values and Units Module Level 3. W3C. 28 August 2012.

I would note that this is still only a draft recommendation, however pixels have been considered an absolute unit in the W3C CSS trail as far back as anything I can see. Andy Dingley (talk) 09:17, 23 September 2012 (UTC)

• The CSS 2.1 recommendation that I cited is final, not a draft. LittleBen (talk) 10:11, 23 September 2012 (UTC)

Pixels are relative units insofar as they rely upon screen resolution. This is measured via the “dpi” (dots per inch) measurement. 72 dpi indicates 72 “dots” (hitherto pixels) per inch. Likewise 96 dpi indicates 96 dots per inch. See: Pixel Density/Pixels Per Inch. This is a widely known metric in the printing industry. Mkmcdonald (talk) 13:09, 23 September 2012 (UTC)

We're not doing printing, we're rendering to a video board. A video device built of pixels.

Note that the W3C (generally considered to know something about web issues) consider pixels to be absolute. Andy Dingley (talk) 14:11, 23 September 2012 (UTC)

• Pixels are dots; pixel density in dpi (dots per inch) is a completely different unit. Neither is measured as a ratio or percentage, so neither is relative. But your relatives may disagree.
• Relative units are also known as dimensionless units. LittleBen (talk) 16:34, 23 September 2012 (UTC)

You are misinterpreting the W3C's page, which is aimed at browser developers. See your own Wikibook (cited), for an explanation of why pixels have been considered relative units in CSS for as far back as I can remember. I was surprised to see the wording in the specs and it appears they flip-flopped on their definition at some point. Ask anyone who uses CSS (as opposed to people who program browsers to apply CSS).

https://www.google.com/search?q=CSS+"pixels+are+relative+units"

See what I mean? Over a decade of CSS developers (and usability experts) explaining how pixels are relative, not absolute units. The semantics change in the specification is irrelevant (and clearly being misinterpreted here). Just goes to show that laymen shouldn't try to interpret technical specifications. ;) — Preceding unsigned comment added by 75.186.15.4 (talk) 18:39, 24 September 2012 (UTC)

• I have cited the W3C and the UN to show that pixels are absolute (fixed) units: neither the web developer nor the browser user can change the physical size of a pixel, it is fixed by the device. The Em and Ex are relative units (measured relative to the font size)—the web developer or the browser user can change their physical size by varying the size of the font. LittleBen (talk) 13:42, 8 October 2012 (UTC)

Verifiability, Relative Units, Pixels, and Propagation of Misinformation

• Back on 11th Sept. User:Ondrejsv reverted claims that pixels are relative units. The Wikipedia rule on Verifiability say that any claims you make must be supported by reliable references. Most educated people know that relative measurements are in percentage or ratio units. Probably you haven't heard of the W3C (Sec. 5.2) or the United Nations, but—as you can see—they say that pixels (px) are absolute or fixed units, not relative. Pixels are relative if you have a relative called Mr. Pixel or Ms. Pixel, but that would still not be a universally-true theory of relativity ;-). Also be sure to read Wikipedia rules on no original opinions and WP:NPOV.
• The writing of the additions can best be described as "highly-opinionated pseudoscientific technospeak gobbledegook". There are no Wikilinks to explain terms that you pull out of the sky, and no references to support your opinion (or your confusion). For example:
• "It is often preferable to use CSS background images that can be switched by media queries and/or handheld style sheets, which can also ensure that layouts don't break (e.g. images displaying outside of their boxes)" does not cite any references.
• The "Confusion and Unobtrusive Javascript" section does not cite any references. Why don't you try to add such confusion to the Unobtrusive Javascript article? You say that "With regard to scripting, progressive enhancement is generally preferred over graceful degradation; however, the strategies are not mutually exclusive", but do not provide any references to support this claim.
• "A JavaScript library is not required to use, and may in fact inhibit, feature detection and testing" does not cite any references. You have removed references to jQuery, JQuery Mobile, and Modernizr without giving any reasons or references that support your viewpoint.
• Wikipedia is not about your personal dislikes—something like (for example), "(I dislike) every major DOM library because each API listed is either poorly designed or a complete waste of time" is not a neutral POV that is supported by reliable references, and so is not acceptable on Wikipedia. Likewise, "I like Internet Explorer".
• A tutorial on "Conditional comments in Internet Explorer" surely does not belong in an article on Responsive Web Design. Wikipedia is not a tutorial, and not an indiscriminate collection of unrelated information.
• "Many older and lesser mobile devices do not support media queries, but a significant number support "handheld" media style sheets (and have since the early part of the century)": again doesn't provide any references showing that browsers of most mobile phones supported "handheld" media style sheets in year 2000.
• The claim that RESS and SASS “techniques are hobbled by browser sniffing” is not supported by any references. A Google reference in this section explains that, “Javascript can be used to display different ad variants on a page”, but you comment that, “unfortunately, this approach requires browser sniffing at some point and is therefore impractical”—without giving any references that show this and prove Google to be stupid.
• You are welcome to parade your total ignorance for a few days, to give you time to find reliable references that support your views, and to give people time to have a laugh (even though it's not April 1st), and then everything that is opinionated pseudoscientific technospeak gobbledegook, devoid of any supporting references or Wikilinks, will be reverted. LittleBen (talk) 10:20, 23 September 2012 (UTC)

You seem content to widely generalise to support your points. Such assertions as “[most educated people agree with me]” have no basis in reality.

I refuted the claim of pixels being absolute units earlier. Any one that is sceptical of the unit’s relativity can find many more links from the print industry and beyond via search engines. What *is* absolute, is that the pixel’s size is dependent upon the input device.

Your call for more references is being received, but I must stress that your partisan tactics are counterproductive. Earlier I did, in fact, provide evidence as to why jQuery Mobile, and by proxy jQuery, are unsuitable for mobile or low-powered devices. The giant mass of script can overload the client and cause the browser to become unresponsive or crash. More powerful devices will have their batteries drained and performance slashed. A logical conclusion is that mobile devices should receive a minimal amount of script. This is advocated by the W3C, specifically, here:

Even where a device does support scripting, do not use it unless there is no other way of accomplishing your objectives. Scripting increases power consumption and so decreases battery life

For more, see: W3C Mobile Web Best Practices.

Furthermore I would like to notify viewers of this page that this snippet:

Wikipedia is not about your personal dislikes—something like (for example), "(I dislike) every major DOM library because each API listed is either poorly designed or a complete waste of time"

has been taken out of context from a personal Web profile of mine in what appears to be an attempt at character assassination. Again, I urge participating members to be wary. There is clearly an agenda behind some activity here.

Finally, I will comment on the thought the Google is a source of poor JavaScript. It is true that Google has a predilection towards poor, often lazy JavaScript. Testing various Google Web services in less capable browsers can easily lead one to the conclusion that they are poorly written. Also note how Google often “deprecates” browsers at will. Another point to note is Google’s constant attacks on JavaScript. First, Google Web Toolkit: a compiler for Java to create JavaScript; second, Google Dart: an alternative to JavaScript that only Google supports. I would not lend credence to a company that heavily relies upon Java-to-JavaScript compilation just to deliver JavaScript for its Web services. Mkmcdonald (talk) 13:54, 23 September 2012 (UTC)

• What about CoffeeScript? Do you prefer BeerScript? LittleBen (talk) 15:31, 23 September 2012 (UTC)

Comments by "David Mark"

Sorry, "Little Ben", but *CSS* pixels are indeed relative (follow the link, which is actually to an affiliated site). Doesn't matter what you are citing that you think means they are "absolute", but you are clearly taking it out of context. Pixels are relative units in CSS, period. It's not a tutorial on conditional comments at all, but an example of "Mobile First". You are the one who originally brought "Unobtrusive JavaScript" into this. I just cleared up some obvious confusion on your part. I'm leaning towards striking that entire paragraph (or moving it to another article). As for SASS, etc. Of course, a server side detection is based on browser sniffing. This is stated in the author's own blog entry on the subject. Did you read it before citing him? As for switching out background images with "mobile" style sheets, obviously you can do that. Doesn't take a cite to prove it. What do you want to cite, the specs for CSS background images? Yes! You can swap them. :) And yes, mobile browsers have had "handheld" style sheets since the early part of the century. I didn't say "most", but a "significant number". I know this from personal experience. As does anyone who was conscious back then. But that doesn't really matter. The main point is that most phones that are in use today have either media queries or handheld support, which makes it very easy to avoid "Mobile First". Regardless, I may reword that sentence. And your "Google must be stupid for that to be true" argument is like something a child would come up with. If it involves browser sniffing, it is stupid (and never mind if Google does it). That point was definitely conceded in the early part of the century and large companies do stupid things all the time. Being large doesn't make them immune to stupidity. ;) Just goes to show that ignorant people can take quotes out of context and sound like they know what they are talking about. Leave this subject alone, please. You didn't contribute much of anything originally and now you want to tear down useful information, simply because it contradicts some of your (and the book's) assertions. And how dare you imply that my contributions are "gobbledygook"? Your original article didn't say much of anything. I do remember it confused the hell out of the PE/GD/UJ issues. I cleared those up pretty well, don't you think? Or perhaps you just don't understand the subject matter and are quoting bits and pieces of blogs and other random pages in an attempt to sound clever. You are in way over your head here. 75.186.15.4 (talk) —Preceding undated comment added 18:18, 24 September 2012 (UTC) Also, what sort of cite do you expect regarding the fact that PE and GD are not mutually exclusive for JS? It's not the sort of thing that is often discussed in major publications. Obviously, if you know anything about the subjects, you know they are not mutually exclusive. It should be quite obvious that they are not mutually exclusive. Discussions of such would not likely be found outside of technical newsgroups, which (last I checked) are ineligible for citing. For the love of God, if the only info about JS, PE, GD, etc. comes from dubious blogs, this will be more of a work of fiction (or an advert) than an encyclopedia. You do realize that JS is the most misunderstood language in history (and that I can cite!) Clearly the related concepts of progressive enhancement and graceful degradation are also widely misunderstood, so there are lots of confused articles out there to cite (I think you cited them all). Again, leave this to people who know what they are talking about. I agree that some of the content can be further polished, but we aren't going back to your nonsense (which absolutely is nonsense). Mentioning scripts you heard about on blogs is not helping to explain what RWD is all about. My six lines of examples illustrates the whole thing concisely (and unfortunately for your ego, it contradicts some of what you wrote). And who is this second author who recommends nothing but browser sniffing techniques? Why is he significant. What if I post a blog entry... https://gist.github.com/3768460 Now I can cite me: "David Mark wrote..." Do you see how stupid it is to ask for cites when you cite blogs and nobodies? Just because you think these two guys are significant doesn't make it so. I think they are both full of hot air (at best). — Preceding unsigned comment added by 75.186.15.4 (talk) 18:30, 24 September 2012 (UTC) Just added several "references". I use the term loosely as I simply Googled and copied links that referenced articles that restated what I said in the first place (just like "Little Ben" does). However, the difference is that I know the correct answers *before* I Google (whereas laymen like "Little Ben" clearly use Google results for education). And neither one of us really knows whether these authors are experts or not. Since when does Wikipedia cite blogs anyway? I suppose you have to for subjects like this, which means that *anybody* could be cited as an expert. ;) 75.186.15.4 (talk) —Preceding undated comment added 19:00, 24 September 2012 (UTC)

• I have explained yet again, one final time, why pixels are absolute (fixed).  LittleBen (talk) 13:49, 8 October 2012 (UTC)

Let's be civil

OK guys. I have come here because a third opinion was requested at WP:3O. I have a number of things to say:

1. I think this might not be appropriate for 3O, so I have left a message at Wikipedia talk:WikiProject Internet#Relative units in the context of responsive web design to see if anyone there wants to help out.
2. Please be WP:CIVIL to each other. When one person is dissmissive of the other it just encourages them to be be dissmissive in return and then you just find it harder to agree.
3. I have not read any of the sources cited, but I am hoping that someone at WikiProject Internet will.
4. From my ignorant perspective either of you could be correct. I suspect that you will find some people who consider pixels to be absolute units and others who consider inches and cm to be absolute, in which case pixels are relative. It may be the case that you want to just tell it like it is: "Important body X describes pixels as absolute units. Well-used manual Y describes inches as absolute and conders pixels to be relative."

Yaris678 (talk) 11:59, 25 September 2012 (UTC)

Browser sniffing, what is it?

For the sake of avoiding argument, can we agree a definition of this?

Does it require (as a defining condition) any or all of the following:

• Executable code
• Executable code that executes on the client
• Executable code that executes on the server

Responding to:

• Discernible differences in the client
• Differences in the client that express varying capacities or features (presence or absence)
• Differences in the client that express attributes as a scalar value (i.e. window size)
• Differences in the client's identity of a device, platform, or browser (where this otherwise arbitrary identity is used as a basis for further judgements, based on implied abilities).

We don't need to agree a definition as to whether browser sniffing is good or bad, although we appear to agree on this.

Otherwise I see future ping-pong wars over whether some aspects of contemporary RWD are seen as sniffing (and thus implicitly bad) or are outside the definition of sniffing (and thus might be good). Andy Dingley (talk) 15:57, 8 October 2012 (UTC)

• Browser sniffing is described in Wikipedia and is Wikilinked in the article. In essence it's a way of asking the browser to tell you its name and major version. A browser can lie about this. And even if you knew that a particular version of a particular browser did not support a particular feature at a certain point in time, this does not mean (or did not used to mean) that there won't (wouldn't) be an update with the same version number that fixes (fixed) the problem later on. So it's unreliable. LittleBen (talk) 16:26, 8 October 2012 (UTC)

WP isn't a reliable source.

I take it from this comment that you would thus not describe techniques of "RWD" as browser sniffing, nor rule them out on that basis, if a server-side operation is performed to test the client's abilities or scalar attributes, and serve varying content on that basis. Andy Dingley (talk) 16:46, 8 October 2012 (UTC)

• Quote: WP isn't a reliable source: true, but it's not always wrong either.
• As the article explains, if you have to support slow circuits and low-end mobile phones (and such conditions still exist in poorer countries), then browser sniffing "guestimation" or device detection (using up-to-date device databases) can be the simplest way. Simple "browser sniffing" has mostly been replaced by "(mobile) device detection". (List of HTTP header fields shows "User-Agent", which includes OS info., and "X-Wap-Profile" for mobile devices—more info. than just the browser version). The two comments like “X techniques are hobbled by browser sniffing” were opinionated, unsubstantiated, and factually incorrect (pure rubbish). With faster devices that support client-side JavaScript, that can be used to test support for features. However, server-side feature detection is also possible, as linked to from the RESS references.
• Javascript-based web analytics like Google Analytics can give statistics for the OS, browser, screen size, even mobile device types and the like for visitors to a web site (using a mixture of the methods described above). LittleBen (talk) 15:26, 9 October 2012 (UTC)

Little Ben, you only cite people that seem to agree with whatever point you are trying to make (often hard to tell what that point is). Whether you do attempt to pigeonhole browsers by UA, other headers or whatever, you are ten years (at least) behind the times. This point was conceded around the turn of the century (which you would know if you bothered to read my numerous citations). None of my points are theoretical; I've been working in this industry for almost twenty years and am quite familiar with the gap between reality and whatever buzzwords the bloggers are pushing this week. Get some experience (or talk to anyone with experience) and then you'll see I am right. Apology accepted in advance. :) 75.186.15.4 (talk) 02:19, 7 January 2013 (UTC)

"With faster devices that support client-side JavaScript, that can be used to test support for features" -Little Ben (of Wikipedia fame) This is what I'm talking about. :( 75.186.15.4 (talk) 02:21, 7 January 2013 (UTC)

In answer to the questions posed: there is both client and server side browser sniffing. The former relies on an optional and non-standard DOM property and the other an optional header (or multiple headers as the case may be). Both are losing propositions, no matter how many losers out there use them (that's sort of the definition of a losing proposition, isn't it?)

The nonsense that starts with "In faster devices..." is typical "Little Ben" brand gobbledygook. And there's no server side feature detection for browsers. Doesn't matter what he's linked to or how he misinterpreted its meaning. It doesn't even make sense.

Here is an article on browser sniffing, written by Richard Cornford (a noted expert on cross-browser scripting).

http://jibbering.com/faq/notes/detect-browser/ 75.186.15.4 (talk) 02:28, 7 January 2013 (UTC)

• Comments below. LittleBen (talk) 13:41, 7 January 2013 (UTC)

HTMLSliceMate spam

Raised at Wikipedia_talk:WikiProject_Spam#Responsive_web_design_and_persistent_EL_to_Responsive_Testing_Tool Andy Dingley (talk) 12:26, 27 November 2012 (UTC)

Reactive Web Design

• This is a reply to User talk:LittleBenW#Responsive web design .28reactive web design.29.
• I had never heard of Reactive Web Design, and—according to Google—the most reliable reference appears to be here: this opinion piece coins the term Reactive Web Design to describe a web page that changes depending on a (e.g. mobile) viewer's location—a local person would get a different page than an overseas visitor or someone located some distance from the location of the cinema or other business that has the web site.
• This concept is quite different from Responsive Web Design. Google advertising is capable of sending a visitor who clicks an AdWords Ad to different URLs depending on whether they are a mobile or desktop user—for example: someone who is using a mobile to find a site dealing in locks is likely to be locked out of a car or house, whereas someone using a desktop is more likely to be thinking of copying a key or changing a lock, for example. But I've never heard this called Reactive Web Design.
• If you work for the web company called Reactive then please be aware of Wikipedia rules on COI.  LittleBen (talk) 12:00, 10 December 2012 (UTC)

Try again Little Ben

Or don't. You don't understand any of what you are editing. That much is clear. Basically, you put back all of your original (and laughable) gobbledygook. You clearly don't understand the terms, patterns or why it is idiotic to reference jQuery in an article about RWD. Leave it alone until such time as you do. Blithering about perceived violations of Wikimedia policy is no substitute for knowing the source material. ;) — Preceding unsigned comment added by 75.186.15.4 (talk) 01:54, 7 January 2013 (UTC)

The comment when reverting the bit about handheld style sheets says it all. It's an old quote from noted "mobile strategist" PPK. Word of advice: don't blindly cite that guy as he's often confused (much like Little Ben).

Read the bit about handheld style sheets again. What did I say about them? Why were PPK and many fellow bloggers confused? Do you get the point now?

https://gist.github.com/3768460

Finally, where do they fit in today (hint: see the helpful examples in the article)? Yes, the ones you keep deleting.

Then there's the revert where you translated my warning about monolithic JS libraries being too large and slow for battery-powered mobile devices to:

"All Libraries are Evil".

That's when I know I'm talking to a pinhead. Re-read and try to understand it this time, yes? :)

75.186.15.4 (talk) 02:39, 7 January 2013 (UTC)

• Most people know that handheld media type is so poorly supported on low-end handhelds as to be useless.
• As has already been explained to you above,

• A tutorial on "Conditional comments in Internet Explorer" surely does not belong in an article on Responsive Web Design. Wikipedia is not a tutorial, and not an indiscriminate collection of unrelated information.
• If Wikipedia were a tutorial (it's not), then a tutorial on "Conditional comments that apply only to Internet Explorer" would be in an article about Internet Explorer, not in an article about Responsive Web Design.

• If you want to post statements like "All Libraries are Evil", then you need to quote a reliable source that says "All Libraries are Evil". Or you could try trashing Wikipedia articles on libraries, or inserting such statements in them, and get yourself blocked.
• Maybe you have never heard of WURFL, etc? WURFL is not Waffle, please don't be confused. LittleBen (talk) 13:26, 7 January 2013 (UTC)

Responsive theme for Wikipedia

I feel like there should be a responsive design for Wikipedia. If one is already out there, it should be noted here. However, I do not know if there is one out there, and on a first search I could not find one. I could make a responsive design for Wikipedia via the User:css and UserJs pages (i.e. doing so is within my skill set), but I thought I'd mention it here first to see if one already exists. Does anyone know of one? Zubachi (talk) 15:49, 14 February 2013 (UTC)

• Please start new talk page sections after the last existing section (I've just moved this to the bottom).
• If you resize the width of your browser window, you will find that the Wikipedia page also resizes, however at present I don't think that images are fluid.
• I believe that there's a mobile-specific Wikipedia site, though I haven't used it.
• You may be interested in the discussions at Wikipedia talk:2012 main page redesign proposal. LittleBen (talk) 16:11, 14 February 2013 (UTC)

• • I know that Wikipedia is fluid-width. But if I'm on a 13-inch screen and split two windows on the left & right of my screen, that leaves very little room for actual Wikipedia content. I find myself using the mobile version more and more often, actually; it's very well designed. The main theme should be made more like that, in my opinion. Similar to the responsiveness of Bootstrap. Zubachi (talk) 00:39, 15 February 2013 (UTC)

How to make Responsive web design tutorial

• How to make Responsive web design

S2ptech (talk) 07:53, 16 April 2013 (UTC)

Sorry but spam links have no place on Wikipedia --Biker Biker (talk) 09:26, 16 April 2013 (UTC)

"NoMoreLinks"

While cross-linking this page to tableless web design (the original Responsive Web Design approach), I noticed a glaring admonition that reads: "DO NOT ADD MORE LINKS TO THIS ARTICLE. WIKIPEDIA IS NOT A COLLECTION OF LINKS ". Partly affronted by the ALL CAPS, and partly affronted by what I see as stifling behavior, I propose a solution that may allow for continued development of this resource and other resources linked to it. Notability guidelines are important.

How about we:

• Create a category page for Responsive Web Design (e.g. Category:Responsive web design)
• Link Category:Responsive_web_design with relevant pages

Wes Turner (talk) 20:28, 17 July 2013 (UTC)

Additional external meta-resources

• http://bradfrost.github.io/this-is-responsive/resources.html
• https://github.com/dypsilon/frontend-dev-bookmarks/blob/master/README.md { Cross Device > Responsive , ctrl-f("responsive") }
• http://filamentgroup.com/lab/responsive_design_approach_for_complex_multicolumn_data_tables/

Wes Turner (talk) 20:27, 17 July 2013 (UTC)

Responsive design / responsive web design

This article has a redirect from Responsive design to Responsive web design - since the theory and terminology of responsive design predates its usage on websites (eg, in architecture), shouldn't Responsive design be its own page which has links to other implementations? Star-one (talk) 14:52, 17 January 2014 (UTC)

I'm assuming lack of response as being assent to this proposal, so I shall get to work in due course. Star-one (talk) 17:20, 28 January 2014 (UTC)

Image

Please could an image be added to this page to illustrate eg desktop and mobile views of same website? Crookesmoor (talk) 13:09, 11 September 2014 (UTC)

History section

Adam's "fluid" is simply the idea of not using fixed-width tables but letting the width vary with viewport.

The paragraph   "Marcotte's techniques ... declarative styling ... direct control of the designer ... would be suitable" appears wrong: with RWD, "layout is fluid" and "images are flexible": they are controlled by viewport size rather than fixed by the designer. The links in the Gillenwater list Liquid/fluid and elastic layouts (deleted) cover techniques dating back to media queries (late 2008/early 2009) providing not only fluid/flexible (Marcotte's narrow definition) but also hybrid fluid/fixed layouts that support fixed-width ad banners. Gillenwater's 2008 Flexible book was pioneering, and her 2010 CSS3 book covers using media queries for RWD (before the term was coined). CSS3 book's sample site.

"RWD" is a concept, not a specific technology/algorithm/protocol. Throughout time and Web/Internet technology evolution, you'll find many other techniques for RWD, whatever the names or synonyms we gave it. The fact that someone wrote a book about it doesn't make him/her the parent/creator of that concept, especially when we know that most of those reference books are written using different findings and solutions from other specialists, if not for a new solution involving new technologies... But it's still the same old concept, as many solutions came along the technologies that were available, and will come along newer technologies in the future : the issue it addresses always existed and was taken into account since the inception of the Web. Some ego would like to be the "father" or "mother" of that concept, but this would make absolute nonsense..

Example :

Myself I've used relative HTML tables since 1995-96 (width percentages instead of fixed pixels for instance, along with some fixed tag values depending on the design at hand - what some call "fluid Hybrid"... lol at names calling). With some CSS when it allowed for relative positioning : CSS being a younger W3C "standard" than HTML, it's implementation from one browser to another wasn't homogeneous, producing rendering differences or even incompatibilities with W3C standards given some browser. Which is why after many try-outs and experiementations - at least on my part -, you can't find many solutions dating from the late 90's involving CSS. But you'll find solutions combining browser sniffers (because there were and still are different ways to render HTML tags/CSS given the browser - however most comply to W3C standards with their implementations nowadays), screen resolution detection (via JavaScript, Perl, Cold Fusion, ASP and such), along what's been named "fluid-hybrid" techniques (relative parameters for table width and such).

I've also created a full-fledged dynamic e-commerce Web site fetching a complex database for eCatalog+Merchants+Trs.gateway+CRM-billing+JIT-supply-chain processing and accounting, out of which a server script could fetch client resolutions history (amongst other data), thus also allowing to lighten the client side in regards to dynamic layout detection request processing. My "team" used snippets of in-house codes, this so-called "RWD" was well recognized, documented and addressed.

In through out other projects, I've documented all those snippets I've created for my dev. "team" (sometimes a "team" of one, other times a "team" of 10, most of the times a "team" of 2-3, not always the same persons thus I needed to create a good reference about this...), either directly on the code files, either in internal documentations, clearly stating and addressing that "RWD" issue. Other times the "team" itself came along with other solutions or modified ones for efficiency given some dynamic visual layout design and the technology at hand (project specifications). With other names : personally I called it "Adaptive Design", other times "Dynamic Layouts", depending if it was a visual design task or a coding task at hand... But who cares really about those specific names I was using, as long as we all knew what we were talking about, which by itself was an evidence.

Well, since I did all the above before 2004, then should I consider myself as the discoverer and father of that so-called "RWD" issue and its solutions/demonstrations? Of course not! As I'm pretty sure that many others also did it, documented it and exemplified it, well before 2004, it would be ridiculous... More over when we were ALL aware of that issue as we talked about it numerous times amongst devs., as a technological evidence. As such evidence we didn't need marketing buzzwords nor "official" name calling, apart standard English and French, so as to depict it (adaptive design, dynamic layouts, whatever), the issue changing faces with the technologies involved.

In fact, and at the risk of looking like if I was bragging, for me and my experience the article that is linked (and the person who's name is attached to this concept), looks like it's been written by some pretentious noob, who found some CSS technique addressing am old issue, but also trying to make us believe that he also discovered (and demonstrated) that issue : trying to "own" it and immortalize his name in Wiki books : this is pure imposture.

Q - "But why didn't they explain this particular issue at school, or in my Frontpage/Dreamweaver/Flash tutorial book with a cool paragraph title like "RWD" before 2004?"

A - Either you wen to the wrong "School for Webmasters", either you took the wrong courses or didn't take the advanced classes... You learned how to efficiently use WISIWIG tools and Web Page design IDE/framework tools (which mostly limited web pages to fixed width, given the nature of NP-Completeness automated code generation can be in this regard), with some HTML and JavaScript concepts for integrating codes (not "designing" codes, as this requires notions in algorithmic - apart from simple JS commands or common small scripts). In short, you haven't actually learned about efficient interface design of Web pages for heterogeneous display resolutions (the fact that it's a screen, a sized/resized Window or a mobile device, makes no difference when coding an appropriate dynamic layout for these possibilities). The term "interface" is important (as it must be an adaptive interface given the variable size of the medium - whatever the device - and variable availability of services). The Web is all about designing an efficient INTERFACE, more than a pleasant and fixed visual design (which is an old leaflet paradigm, from the print industry and unidirectional/inappropriate marketing concepts pertaining to advertisement), for navigating structured information and act upon it. This may oblige to go much further into some learning process and experimentations, as a very good knowledge of at least HTML/CSS as well as programing/computational paradigms are required.

--HawkFest (talk) 14:09, 2 February 2015 (UTC)

Mashable was incorrect, as we see now. A phone is a phone, and can never be "responsive" enough to do real spreadsheets, word-processing. In other words, Real Work. "One size fits all" doesn't work - never has, never will. Too many compromises have to happen to make anything work at all, and by the time the product (so-called) is "done", it's usually so stripped of functionality, it's basically worthless. There is no cost savings to be had. Phone / mobile apps exist in their own, unique ecosystem, and cannot be leveraged upward, or downward for that matter. An apple is not an orange. Pun possibly intended. — Preceding unsigned comment added by 98.194.39.86 (talk) 07:57, 8 November 2016 (UTC)

Opening sentence

Not sure about "scrolling" in "to provide an optimal viewing experience—easy reading and navigation with a minimum of resizing, panning, and scrolling". It's becoming clearer that scrolling with a swipe is preferable to clicking (with a tap) as an easier gesture on a smartphone. — Preceding unsigned comment added by Geekpie (talk • contribs) 10:20, 17 December 2014 (UTC)

History section : lie and imposture

The History section states the following: A site layout example that adapts to browser viewport width was first demonstrated by Cameron Adams in 2004....

Well I must say that this is plain false, he surely was not the first to do some "demonstration" about this issue (the one that's linked reminds me of old HTML/CSS reference books and Table examples from 1995-1998). Not the first either to think about cross-browser/cross-resolution/cross-platform layouts and designs (as is also linked), a much older, broadly recognized and documented Web design issue, well before 2004.

This is a preposterous imposture!

The link only shows one of the myriads of solutions that have been given throughout time and technologies since the 90's, by myriads of serious Web developers around the globe. The fact that someone called it "RWD" instead of finding a new solution, changes nothing about this reality.

So please someone remove such reference to the name. If I don't get any feedback about this message, in about a week I will do it myself and try to replace the text with something else. --HawkFest (talk) 17:32, 1 February 2015 (UTC)

History in error

Please refer to talk on French article, subject Autres approche. were I explained brievly an other implementation of responsiveness done at Air Canada around 1995 with rheir Self-serve kiosk able to display on PC screen as well as on Palm pilot among others planned but not realized--69.70.196.38 (talk) 16:24, 17 August 2015 (UTC)

IP added External link for Reasons to Choose Responsive Website Design

An IP editor added an external link,Reasons to Choose Responsive Website Design, to the bottom of the page. I will do an Assume good faith revert because it was placed in the wrong section, there is no External links section, & there is an {{No more links}} template directing any discussion of new external links to this discussion page. Peaceray (talk) 16:25, 11 January 2016 (UTC)

The amount of mobile traffic now accounts for more than half of total internet traffic?

My gut feeling said that I found this hard to believe. So I checked the source. I did not read it all, I scanned through large parts, but I could not find it. The closest was figure 25; it depends on how you define mobile traffic, but it still only passes the 50% mark in the prognosis for the future, not in the actually measured data. So unless someone can find it in the source, it seems an unsourced statement; in fact, the source seems to contradict the statement. It should then be removed.

(Rest is an aside, feel free to skip it) I'm still quite surprised by the numbers though; is this really all public IPv4/IPv6 traffic from all IP traffic generating devices? E-mail spam, VoIP including backhaul for regular telephony, video conferencing, HD video streaming, game downloads, file transfers and software updates, academic datasets, all those bandwidth eaters and more, losing the competition to a device explicitly designed to be conservative with data bandwidth? I've never really studied the subject, but I find it quite surprising indeed. Digital Brains (talk) 14:37, 22 May 2016 (UTC)

See here: http://marketingland.com/mobile-top-sites-165725 for a source on mobile traffic overtaking desktop. | MK17b | (talk) 04:37, 6 June 2016 (UTC)

Thanks for the link! However, that does not say that over half of the total internet traffic is caused by mobile. It talks about web traffic only: it excludes anything that is not a website. My proposal is to reflect this in the text and use either this source or the source of this source. It is more relevant anyway; the article is about web technology, so the only relevant statistics deal with web traffic, IMO. Digital Brains (talk) 10:18, 6 June 2016 (UTC)

References

"Fluid Grid"

The description for fluid grid at the top is now incorrect:

"The fluid grid concept calls for page element sizing to be in relative units like percentages, rather than absolute units like pixels or points."

should be changed to:

"The fluid grid concept calls for page element to be made of blocks of static width, which can be dynamically placed, depending on the width of the viewer."

as can be verified with adobe's fluid grid (http://www.adobepress.com/articles/article.asp?p=2126863) and W3's fluid grid (http://www.w3schools.com/w3css/w3css_grid.asp)

... agree? — Preceding unsigned comment added by 99.239.101.126 (talk) 00:51, 25 July 2016 (UTC)

Client Side Responsive Web Design

For sites that are being created on the fly or web developers just learning front-end we could lightly cover the benefits and techniques used on how to obtain a responsive feel with client-side coding. There has been a bit of coverage on server side handling on responsive design and we could also include this piece out to keep a balanced page

https://css-tricks.com/the-difference-between-responsive-and-adaptive-design/

— Brian779 (talk) 06:10, 23 February 2017 (UTC)

Responsive web design soon to be called Mobile Web Design

In short the terms Responsive and fluid websites referral is to Mobile devices. There has been a lot of discussion of this termination will be shortened to a simple understanding of the phrase and meaning. In Short Mobile Web design. Will be done by a Mobile Web Designers.ie Mobile designers. Mjd218 (talk) 23:07, 12 February 2018 (UTC)

No. Andy Dingley (talk) 00:24, 13 February 2018 (UTC)

Tech SaraZ self insert

The latest edit is by a user Techsaraz who inserted replaced a mention of an article with a mention of their own blog/website. The actual reference was not changed however. I suggest reverting the edit as it is confusing and self promotion as well as suspending Techsaraz's wikipedia account. 62.144.229.221 (talk) 07:47, 24 August 2023 (UTC)