Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: Responsive Web Design

samzenpus posted more than 2 years ago | from the read-all-about-it dept.

Book Reviews 59

Michael J. Ross writes "With more people accessing the Internet using mobile devices than computers, web designers and developers are challenged to make sites that work well on both categories of hardware — or resign themselves to the greater costs and other disadvantages of maintaining two versions of each web site (a mobile-ready version as well as one for much larger screens). Fortunately, recent advances in web technologies are making it easier to build web pages whose contents and their positioning are automatically modified to match the available screen space of the individual user. These techniques are explored in detail in a recent book, Responsive Web Design, written by Ethan Marcotte, a veteran web designer and developer." Keep reading for the rest of Michael's review.This title was published on 7 June 2011, under the ISBN 978-0984442577, by A Book Apart, as the fourth in their series of "brief books for people who make web sites." On the publisher's page, visitors will find brief descriptions of the book and its author, links to purchase the print and e-book versions (or the two combined, at a substantial discount), and three promotional blurbs also used on the back cover of the print version. The e-book package consists of six files: the book in EPUB, MOBI, and PDF formats; an EPUB document on responsive design for video; a letter from Jeffrey Zeldman (the book's publisher), Jason Santa Maria (its designer), and Mandy Brown (its editor); and the previous five files zipped into an archive. This book is also available in French, perhaps reflecting the publisher's greater awareness of internationalization relative to mainstream technical publishing houses.

Readers of the print version will likely be first struck by its diminutive size — just 143 pages. In fact, the book is so slender that only half of the spine title actually fits on the spine. (It's either a bold design statement against conventional publishing practices, or an even bolder typographical error committed inexplicably by a well-regarded design firm.) Flipping through the glossy pages, readers will also notice the judicious use of text color to indicate HTML and CSS code, and highlighted fragments therein. Even more visually impressive are the full-color screen shots and other figures. The book begins with the previously mentioned letter, as well as a short yet delightful foreword by Jeremy Keith; it ends with the author's acknowledgments, suggested resources, references by chapter, and a suspiciously brief index, not much longer than the author bio that follows it.

The bulk of the information is organized into five chapters — the first of which, "Our Responsive Web," presents a high-level rationale for architecting web sites that can be maximally useful on a wide range of devices, with screen sizes ranging from the smallest found on smartphones, up to widescreen TVs attached to web-enabled game consoles. Throughout the book, to illustrate the principles of responsive design, the author utilizes a fictional example web site, "Robot or Not", designed to assist users in identifying robots masquerading as humans (which would have been helpful to the crew of the spaceship Nostromo!). This short chapter is essentially just an introduction.

The author gets down to business in the second chapter, titled "The Flexible Grid," which demonstrates how grid-based layouts can be used to more easily position page elements for greater visual consistency. He goes into detail in showing how such layouts can be made flexible, with font sizes specified in character widths and positioning specified in proportions of containing elements. Experienced designers will probably not encounter any new concepts in this material. These techniques are extended in the subsequent chapter, "Flexible Images," which explains how to use percentages when working with images (both markup and CSS) and other media types — including workarounds for the browser most despised by web designers, Internet Explorer.

Media queries, introduced to the world in CSS2, are now a key technology in responsive design, and are discussed in Chapter 4, which forms the core of the book. The author shows how to use them to cause the browser to apply CSS rules selectively based upon such factors as the width of the browser viewport. All of the narrative is clear, except for the statement on page 66 that the example web site's logo is "scaled down to a nearly microscopic size" in Figure 4.2, when in fact it appears unchanged. Readers may wonder why — after noting that mobile devices do not consistently use "handheld" or "screen" as their media types — the author does not explain why the recommended media queries use "@media screen," and not "@media all" to be more encompassing. Nonetheless, the discussion of media query techniques is instructive. It continues with a look at how to use them in older browsers, using JavaScript libraries, css3-mediaqueries-js and Respond.js. Lastly, the author shows how incorporating some fixed widths into a flexible design may be an optimal approach.

The fifth and final chapter, "Becoming Responsive," discusses real world implications of responsive design. The author counters an interesting contention: web sites on mobile devices should not simply be the desktop content scaled down to a smaller screen, but instead should offer different content, more appropriate for the individual on the go. He then touches on the topic of designing sites first for mobile, rather than the traditional approach of trying to shoehorn a full-size site onto a small screen. The bulk of the chapter is devoted to presenting a workflow employed by the author in creating actual client sites. It concludes with a demonstration of how to add a slideshow using a jQuery plug-in and some custom code, so it abides by the principles of progressive enhancement.

In terms of the physical book, the quality is top-notch, and the full-color images are quite compelling. Sadly, each figure tends to bleed through to the other side of its page, but fortunately not enough to inhibit reading the text on the other side, or appreciating any of the images. The e-books are also quite readable — probably more so compared to the electronic versions of other programming books, given the smaller line lengths.

In terms of the narrative, Ethan Marcotte has a somewhat goofy writing style, replete with nerdy side comments and jokes, which some readers may regard as padding, particularly in those sections where they are quite numerous. The same may be said for the hyperbole in some spots, such as "Marvelous. Wonderful. Stupendous, even." (page 33). On the other hand, many readers may enjoy the lighthearted style, especially those jokes that work well. More importantly, the explanations are generally comprehensible and thorough. I was able to find only one erratum ("or a maybe an animation," on page 119), and the only grammatical error was the frequent use of the term "that" to refer to people, instead of "who." Otherwise, there were no glitches in the writing, and most techies will find this book a fairly quick read.

From a higher-level perspective, one sometimes hears an objection raised against web design/development books such as this one — namely: all of the book's information is freely available in articles, blog posts, forums, IRC channels, and other resources for programmers. So why purchase a static book whose author probably started writing it months if not years in the past? Such technical information is scattered among numerous websites, thereby forcing us to spend time searching around, and in many cases skipping over redundant material. Also, the advice tends to vary in quality, and hence we must distinguish what information is out of date or simply invalid. Likely every experienced developer has been tempted by an article titled such that it sounded as though it would contain the exact solution to the problem at hand — only to discover that the title was quite misleading, or the people contributing to the comments were equally befuddled (and frustrated). Technical books geared toward the working professional can obviate these problems, because they bring together most of the information known by the industry, into a cohesive whole, that is then vetted by technical reviewers and editors. In the case of this monograph, Ethan Marcotte's well-regarded seminal article, in conjunction with the other most popular articles on responsive web design, would still not be a sufficient substitute for this resource.

For web designers and developers alike, Ethan Marcotte's book is a neatly-crafted and authoritative single-source tutorial on how to build responsive web sites that will likely prove robust on a wide range of platforms.

Michael J. Ross is a freelance web developer and writer.

You can purchase Responsive Web Design from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

59 comments

How about (3, Interesting)

ackthpt (218170) | more than 2 years ago | (#38195540)

Starting with Web Pages That Suck [webpagesthatsuck.com] and learning there before doing anything.

Amazed how many pages get it wrong - from Facebook to Ebay - there are fundamental navigation design flaws which vex users. There's some sort of disease, which has been epidemic for years on the web, steering wide of the Keep It Simple Stupid philosophy of design. Keep in direct, simple and above all light weight.

Mystery meat in Unity (1, Interesting)

tepples (727027) | more than 2 years ago | (#38195644)

Starting with Web Pages That Suck

If only the architects of the Ubuntu operating system would read that web site. Then they'd understand what the global menu in Unity does wrong compared to the global menu in, say, Mac OS X. In Unity, the frontmost window's title covers up the menu bar until the mouse enters the menu bar. WPTS calls this behavior mystery meat navigation [webpagesthatsuck.com]

Re:How about (0)

fiannaFailMan (702447) | more than 2 years ago | (#38197238)

Starting with Web Pages That Suck [webpagesthatsuck.com] and learning there before doing anything.

Did they nominate themselves for any award? I went hunting for the list of 2011 contenders and it took about four clicks of links, each of which promised me I was going to get to the 2011 contenders. Every time I clicked a link it opened it in a new window. The ads were so intrusive I didn't know if they were bitching about the companies advertising on their page or something else.

Re:How about (0)

Anonymous Coward | more than 2 years ago | (#38201974)

Thank you - that site is just as bad as the ones they're bashing. Not to mention, a would-be Web designer needs to look at and study sites that DO work, don't waste time on sites you consider ugly or non-functional. It's a waste of time.

How about not worrying about it (1)

VernonNemitz (581327) | more than 2 years ago | (#38199020)

As technology improves the screen sizes of handhelds will get bigger, most probably by unfolding --one such unit is already available. Also, if their pixel resolution improves, then that is another way for them to emulate a larger screen. So, this is really a short-term problem, provided that web-page designers don't design for wide-screen monitors. Good old 800x600 or 1024x768 is probably fine.

How strange (2, Insightful)

Anonymous Coward | more than 2 years ago | (#38195580)

I thought the whole idea of HTML was that content and presentation would be separated so you wouldn't have to care whether the end-user was viewing the page on an SGI workstation in Spielbergian 3D or an Etch-a-sketch?

Of course that was before the 'web designers' came along and suddenly 'this page is best viewed at 1280x1024' was plastered across the web.

Why serve both low- and high-detail HTML (2)

tepples (727027) | more than 2 years ago | (#38195710)

I thought the whole idea of HTML was that content and presentation would be separated

On a device with a high-definition screen, such as a PC, Internet-enabled television, or full-size tablet, a news site might want to show both the headline, a photo thumbnail, and the first sentence of each article. But on a device with a smaller screen, such as a PDA or mobile phone, it might want to show only the headline. CSS can only hide boxes; it can't keep the boxes from being downloaded in the first place. Furthermore, the devices with small screens often have Internet connections that cost more per bit than the devices with big screens. So you usually want to redirect small-screen users to a low-detail HTML document and large-screen users to a high-detail HTML document.

SO USE SEPARATE WEB SITES! (0)

Anonymous Coward | more than 2 years ago | (#38195864)

If what you describe is really a problem, then the only sensible thing to do is to use two completely separate web sites. You have one targeting mobile devices, and one targeting more capable devices.

WHY THE FUCK DO WEB DESIGNERS FEEL THE NEED TO TARGET EVERY POSSIBLE DEVICE WITH A SINGLE WEB PAGE OR SITE?

It sure as fuck isn't a "cost saving" measure, because these web designers will spend far more time fucking around with CSS to make the pages render everywhere than they will spend if they just make two separate implementations.

...on the same hostname (1)

tepples (727027) | more than 2 years ago | (#38195956)

If what you describe is really a problem, then the only sensible thing to do is to use two completely separate web sites. You have one targeting mobile devices, and one targeting more capable devices.

Which is sort of what I meant by "redirect small-screen users to a low-detail HTML document". Viewing the front page of a site on a PDA or cell phone would redirect to /m/; doing so on a PC or TV would redirect to /home/.

Re:...on the same hostname (1)

jc42 (318812) | more than 2 years ago | (#38209588)

Viewing the front page of a site on a PDA or cell phone would redirect to /m/; doing so on a PC or TV would redirect to /home/.

So can you show us the code on the server that determines the size of the screen (or window) at the client end?

This turns out to be a non-trivial problem. If the Web's standards stated that the client had to send this information, it would be easy. But this hasn't been done. The only "solution" seems to be to use the HTTP_USER_AGENT string, which isn't actually sent by all clients, and which has millions of possible values, some of which don't tell you much about the window/screen size. People who have tried to build a table based on what browsers send have reported using a GB or more of memory, and still not getting it right for many current clients.

Actually, on some recent sites I've built, I've taken care to eliminate all uses of size= or width= or other format-restricting HTML/CSS thingies, with the idea that the client's browser can format it to fit. This does work with a lot of browsers. It fails spectacularly with the iPhone's browser, which formats the text for a much larger screen, then shrinks it to fit, giving what looks like a 3x2 font size. Grrr ...

When I first ran across this, questions on a number of forums turned up the suggestion that I just include <meta name="viewport" content="width=320"> when the HTTP_USER_AGENT includes "iPhone". I did that, and it worked - for a while. Now, of course, there are iPhones with screens with higher resolutions. So I've commented that code out, and given up.

Maybe what we need is a crowd with torches and pitchforks descending on the W3C's offices, demanding that they add a requirement that clients divulge their window/screen pixel size to the server software.

Or maybe we can demand a requirement that, if a web page is too big for the client's window/screen, the client is required to discard all size restrictions, and revert to full reformatting to fit. It's not clear how one might enforce such things on random web clients, however. They haven't been all that successful at enforcing previous standards, after all.

Re:SO USE SEPARATE WEB SITES! (4, Insightful)

Eskarel (565631) | more than 2 years ago | (#38197322)

For the most part they don't. In fact I don't know of anyone who actually does that successfully.

The author of this book seems to think it's a good idea, but generally speaking I've never known anyone halfway sane who did it more than once by choice. Sometimes you'll get the content vs presentation brigade self flagellating with this kind of design, but these are the same people who think that the web is a place where you can actually follow best practices and end up with a meaningful result.

Sorry to burst everyone's bubble, but the Web is a dirty dirty place. The W3C likes to finally set standards for things that were needed 5 years ago and never for what's needed now, AJAX is a dirty hack which just happens to work well, and everyone on the standards body seems absolutely obsessed with building more and more functionality for static web pages which make up less and less of content and didn't really need any help to begin with. Half of HTML5 is semantic web garbage, which is great in theory, but which is almost entirely focused on last decade's content.

Re:Why serve both low- and high-detail HTML (1)

Gadget_Guy (627405) | more than 2 years ago | (#38196154)

On a device with a high-definition screen, such as a PC, Internet-enabled television, or full-size tablet, a news site might want to show both the headline, a photo thumbnail, and the first sentence of each article. But on a device with a smaller screen, such as a PDA or mobile phone, it might want to show only the headline.

With the amount of Javascript and appallingly bloated HTML on some news sites, I think a small amount of extra text per story that gets downloaded but not shown will pale into insignificance. And if they want to include a picture, then they can use CSS to apply it rather than use the <img> tag, so it would not get downloaded if it doesn't match the media type. I guess that does blur the line between content and presentation though.

The best practice is to write pages that flow naturally to the screen width. I have had to use the mobile version of a webpage before when the main website would not fit onto the screen of my notebook computer. The problem with having the mindset of separate versions of the website (to quote the summary: a mobile-ready version as well as one for much larger screens) is that it can miss out on the screen sizes in between (eg. netbooks). But if you make a single page that scales well, then there is no single defined concept of a small screen.

Make it wide enough for netbooks and Snap (1)

tepples (727027) | more than 2 years ago | (#38196618)

And if they want to include a picture, then they can use CSS to apply it rather than use the <img> tag

Since when can a CSS background-image be scaled?

The best practice is to write pages that flow naturally to the screen width.

True, but there's still a reason to put something like max-width: 30em on a body text element, and it's the same reason newspapers are printed in columns instead of with lines of text across the whole width of a half-broadsheet. Without it, the eye has trouble finding the start of the next line of text, and the reader may end up repeating or skipping a line.

The problem with having the mindset of separate versions of the website (to quote the summary: a mobile-ready version as well as one for much larger screens) is that it can miss out on the screen sizes in between (eg. netbooks).

Then make your "full size PC" page scale as small as netbooks, but not necessarily smaller. A lot of web sites already employ grids roughly 900px to 960px wide, which fits into a netbook's screen as well as a browser window that has been Snapped to the left or right half of a 1080p monitor. But it's a lot harder to make a web site that presents the same amount of information on a 3.5" screen without having the scrolling column so tall that nobody can find anything.

Re:Make it wide enough for netbooks and Snap (1)

Gadget_Guy (627405) | more than 2 years ago | (#38197224)

And if they want to include a picture, then they can use CSS to apply it rather than use the <img> tag

Since when can a CSS background-image be scaled?

I'm not saying that you should scale the image smaller on smaller window sizes. I am saying to remove the image at small resolutions. That is easily done with CSS.

there's still a reason to put something like max-width: 30em on a body text element

That is one strategy for making the page resize as I stated, and yet it prevents the page from becoming stupidly unreadable on large monitors. It is certainly better than just using width: 30em. That said, you don't want to make the max-width too narrow. It is annoying to maximize a window to see more of a webpage, only to be greeted with exactly the same layout as the windowed browser.

Then make your "full size PC" page scale as small as netbooks, but not necessarily smaller.

Why? Because it is harder to make a page that scales well? It is true that it takes a little bit more planning, but this is offset by eliminating the need to keep two different websites up to date.

A lot of web sites already employ grids roughly 900px to 960px wide, which fits into a netbook's screen as well as a browser window that has been Snapped to the left or right half of a 1080p monitor.

That would fail for 800x480 netbook screens. Or people on 1280 width screens who do not maximize every window. That is exactly my point: whatever assumptions you make about the client's environment, someone out there will prove you wrong.

Re:Make it wide enough for netbooks and Snap (1)

jc42 (318812) | more than 2 years ago | (#38209776)

That would fail for 800x480 netbook screens. Or people on 1280 width screens who do not maximize every window. That is exactly my point: whatever assumptions you make about the client's environment, someone out there will prove you wrong.

Heh. I've found myself often adopting a practice that helps prevent a single web site from occupying most of my screen: If I see a "mobile" link, I automatically click on that one. Such pages are quite readable on this 1920x1200 screen, and leave most of the other stuff still visible. And the "mobile" pages tend to omit a lot of the cruft that clutters up most "main" pages, so I often see more actual information that way. I did this with slashdot, before they provided a layout that used the full window width to display articles and root comments.

I've done this occasionally in front of the web developers, who seem to sputter a bit, and are clearly offended with my audacity. If they ask about it, I bring up their two pages side by side, the same size, and point out that the "mobile" page contains more information, so it's clearly superior. It's fun to watch their reactions to this.

I also do this routinely with several sites that I've developed. This is due to the site's owners insisting on the common design with a big logo bar at the top, a nav bar at the left, an ad bar at the right, and whatever space is left in the middle for content. That's what they wanted, but I also supply the simplified "mobile" version with a shrunken logo and an abbreviated nav bar at the top, then the content at full width, and the ads at the bottom. Their customers appreciate this, and I find that "mobile" page much easier to use for my testing (with a final check that it works in the "Full" layout).

I'd say that life will be easier when the clients will let us developers dispense with the multiple versions. But of course, by then there will be other design fads that they insist on, which look flashy but interfere with clients' access to actual information.

Re:Make it wide enough for netbooks and Snap (0)

Anonymous Coward | more than 2 years ago | (#38197764)

>Since when can a CSS background-image be scaled?

Since CSS3?

IE pre-9 is still nearly half (1)

tepples (727027) | more than 2 years ago | (#38198130)

And since when does the latest version of the web browser bundled with the most common PC operating system support CSS3? The most common PC operating system is still the ten-year-old Windows XP, and the latest IE for that is IE 8. As of July 2001, IE 6 through 8 had a 44.7% total usage share according to Net Applications.

Re:IE pre-9 is still nearly half (0)

Anonymous Coward | more than 2 years ago | (#38199302)

>bundled

That's your problem (aside from IE == browser thingy). Also, it does not change the fact that it exists. That's what the question asked for.

Re:IE pre-9 is still nearly half (1)

tepples (727027) | more than 2 years ago | (#38200886)

Then perhaps the key word isn't "bundled" as much as "already installed when the user sits down". "Exists" works only if you are using a computer that you own. Someone browsing on break at work or browsing from a public library or a university computer lab doesn't necessarily have the choice to install another web browser. Would you be willing to risk your company's reputation on a stylesheet that will render wrong for 44.7% of users?

Re:Why serve both low- and high-detail HTML (1)

Lumpy (12016) | more than 2 years ago | (#38196260)

So you cant make the php or asp code also see what the browser is and adjust?

If you have "articles" and run flat html and css you need to stop right now and get out of the web design business.

Use separate URLs to be cache friendly (1)

tepples (727027) | more than 2 years ago | (#38196672)

So you cant make the php or asp code also see what the browser is and adjust?

One can, but to take cache behavior into account, one needs to put the PHP or ASP code that generates the low- and high-detail documents at different URLs and then do "Location: /home/" or "Location: /m/" depending on the detected user agent. Each document in /home/ or /m/ would link to the corresponding document in the other space in case the script misdetects the user agent. Otherwise, if you put the home and mobile documents at the same URL, a caching proxy might deliver the document suitable for the device that the previous user was using instead of the document suitable for the present user's device.

Re:How strange (1)

ackthpt (218170) | more than 2 years ago | (#38195862)

I thought the whole idea of HTML was that content and presentation would be separated so you wouldn't have to care whether the end-user was viewing the page on an SGI workstation in Spielbergian 3D or an Etch-a-sketch?

Of course that was before the 'web designers' came along and suddenly 'this page is best viewed at 1280x1024' was plastered across the web.

I have a considerable background in developing very lightweight web interfaces. Use no more than necessary to accomplish your goal. But then, I do a lot of the coding by hand, still. Composition tools in the hands of morons are responsible for most of the web's disasters. Why bother to understand the footprint and implications of each object added to a page when it's so easy to do? I finally had to go to DSL at home when my poor 56K modem was choking on bloat - good by $12/mo. internet.

Ergonomics aren't considered much, either. I regularly have to work on a site where other users are stating concern about repetitive stress injuries, due to the excessive number of links we have to navigate to get something done, which shouldn't be anywhere near as cumbersome - the site breaks quite a lot, too. With complexity increases the likelihood of introduction of flaws in the design. Jurassic Park should be required reading for web designers, and I don't mean the bits about all the running around being chased by dinosaurs - pay attention to mathematician and chaos theorist, Ian Malcolm.

Not so much, actually (0)

Anonymous Coward | more than 2 years ago | (#38195976)

It's "markup" for surrounding content. There was no separation intended there.

You're probably thinking of XML and XSLT and/or CSS.

Re:How strange (1)

jc42 (318812) | more than 2 years ago | (#38209384)

I thought the whole idea of HTML was that content and presentation would be separated so you wouldn't have to care whether the end-user was viewing the page on an SGI workstation in Spielbergian 3D or an Etch-a-sketch?

Actually, that was one of the primary design goals in Tim Berners-Lee's original HTML. The "markup" was explicitly designed so that when the text reached the client's machine, it could be quickly and easily formatted to fit whatever screen was available.

Of course that was before the 'web designers' came along and suddenly 'this page is best viewed at 1280x1024' was plastered across the web.

I think you nailed it! But we might add that this contempt for the viewer was encouraged by many managers, who just wanted it to look good on the screen that was on their desk. I've worked on any number of projects where, once it worked on the Boss's screen, I was explicitly ordered to make it look exactly the same on all other screens.

In a few cases, we were able to quietly remove all the width= attributes and such format restrictions after a while, and nobody noticed. But in many cases, ongoing testing checked to make sure we weren't sneaking in things that made the pages work on small ("unapproved") screens. So yes, much of the difficulty in using the Web on small portables was done with malice aforethought, by the people in charge of Web development projects.

I guess we can be smug in the knowledge that they're now paying for their antagonism toward (potential) customers, by their need to redesign the stuff that they knowingly and intentionally misdesigned some years back.

(Actually, I've always sorta wondered why browsers don't come with a Preferences setting to ignore all sizes and other formatting attributes. And shrink all images to a thumbnail by default. You'd think this would be a no-brainer. ;-)

This is new? (1)

arthurpaliden (939626) | more than 2 years ago | (#38195680)

I seem to remember that was what the initial release of HTML did. And as I recall it did it quite well. It displayed structured data to fit the display device.

Re:This is new? (2)

MightyYar (622222) | more than 2 years ago | (#38195906)

HTML did okay until you started playing with tables. And many content-only sites would do well to return to simpler layouts.

But applications-in-the-browser that use tons of javascript can't really fall back to plain HTML.

Re:This is new? (3, Funny)

tepples (727027) | more than 2 years ago | (#38195998)

But applications-in-the-browser that use tons of javascript can't really fall back to plain HTML.

If some vocal opponents of web applications are to be believed, JavaScript-heavy web applications can fall back to offering a download of the installer for a native application designed to run in Windows and Wine and a download of an APK designed to run in Android.

Re:This is new? (1)

MightyYar (622222) | more than 2 years ago | (#38200550)

Lol, even adobe couldn't pull that off with their flash plugin. Better to let the individual vendors write their own bugfixes. Maybe google will get some traction with their sandboxes native code in the browser idea.

Book Review? (-1, Troll)

Anonymous Coward | more than 2 years ago | (#38195690)

Why is this marked as a book review? It can't be, it's not from Packt Publishing and it's not about Drupal....

XSL would be awesome (0)

Anonymous Coward | more than 2 years ago | (#38195696)

You know. Using XSL stylesheets to generate (and render) the HTML in the browser and only transfer XML to the browser and requests from the browser to the httpd.

But then there are the retards from Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=98168 [mozilla.org] (Bug filed in 2001)

Well... one can dream.. about responsiveness...

Re:XSL would be awesome (1)

tepples (727027) | more than 2 years ago | (#38195726)

requests from the browser to the httpd

Each of which requires a separate round trip over a potentially high-latency Internet connection, making the site load more slowly.

Re:XSL would be awesome (0)

Anonymous Coward | more than 2 years ago | (#38196066)

LOL

you have no clue what OP wrote about.. or how HTTP works... i think you know nothing except how to reply to slashdot comments and make yourself look stupid.. you even registered here to write your stupid comments more frequently...

Re:XSL would be awesome (1)

tepples (727027) | more than 2 years ago | (#38196476)

you have no clue

Then please give us some. Say you want to display only the headlines to users of a PDA or mobile phone but the headline, the first sentence of the article, and a photo thumbnail to users of a full-size tablet, a PC, or an Internet-connected TV. How would you do this using XML and XSLT?

Re:XSL would be awesome (0)

Anonymous Coward | more than 2 years ago | (#38196884)

now you are talking about "how to select(!) and transform information from the XML using XSLT"...
answer: XPath queries

but in your other reply you were talking gibberish about separate round trips and high-latency... something different..

i think you got angry and bitter by technology that is way over your head and now you want to fight it out with changing arguments on slashdot...

Re:XSL would be awesome (1)

tepples (727027) | more than 2 years ago | (#38200916)

now you are talking about "how to select(!) and transform information from the XML using XSLT"...
answer: XPath queries

You can only "select" information without a round-trip if you have already downloaded it. This means your low-detail document will have as many bytes as the high-detail document, which defeats the purpose of sending a low-detail document over a more expensive Internet connection.

Re:XSL would be awesome (1)

Coriolis (110923) | more than 2 years ago | (#38199896)

I can only presume you haven't tried this. It's completely at odds with most shops' workflow, where designers produce graphical representations of how the site should look, which are then converted to HTML and CSS, which are then turned into templates by developers, which are then populated by values taken from your object model which is populated from a database. Dropping XSL into the mix adds the complications of converting the object model to XML and breaking the HTML up into sensibly-sized XSL templates (which additionally makes it impossible for anyone who doesn't understand XSL to maintain).

But... (-1)

Anonymous Coward | more than 2 years ago | (#38195706)

But... I come to Slashdot for shill reviews for Packt Publishing and their books on 3 year old versions of Drupal. Slashdot I am disappoint.

Re:But... (1)

tepples (727027) | more than 2 years ago | (#38195772)

Anonymous Coward wrote:

I come to Slashdot for shill reviews for Packt Publishing and their books on 3 year old versions of Drupal. Slashdot I am disappoint.

Would a 1 1/2 year old book by RuPaul [amazon.com] make you feel better?

Re:But... (1)

MikeKWarren (2467784) | more than 2 years ago | (#38216552)

not sure your point....

Simple Solution to Faster Web Pages (4, Informative)

Lawrence_Bird (67278) | more than 2 years ago | (#38195886)

1- do not serve ads from remote servers
2- do not associate with external sites like facebook, etc
3- do not use web bugs, beacons or other trackers

Those three things probably account for 99.9% of the sloth in today's internet

Re:Simple Solution to Faster Web Pages (1)

MachDelta (704883) | more than 2 years ago | (#38196028)

I just love it when I find myself at a new (to me) website, and open up the noscript dialogue box to whitelist that domain, and I can't even find the thing because it's grabbing crap from fifteen different places. Usually that's my clue to leave, but it seems to be happening more and more often now.
That, and websites that just love having a completely separate domain for images, video, and regional content, and then they smash it all into one page. That pisses me off too. I weep for the death of subdomains.

Re:Simple Solution to Faster Web Pages (3, Informative)

Reigo Reinmets (1035336) | more than 2 years ago | (#38196548)

Having a separate subdomain for images, video and content can actually improve speed when those subdomains are cookie-less and properly cached. Although having one subdomain like that would be preferred. Also, many developers are using Google(or others) CDN for javascript frameworks and popular API's to improve loading speed(You are very likely to already have the Google CDN JQuery in your browsers cache) and reduce bandwidth usage.

Re:Simple Solution to Faster Web Pages (1)

TheModelEskimo (968202) | more than 2 years ago | (#38197090)

>1- do not serve ads from remote servers

Not everyone needs to do this, but many rely on ad revenue in order to keep running their websites. So good luck with that.

>2- do not associate with external sites like facebook, etc

Shouldn't this depend on your marketing plan and target audience, and the sites they like to use? Oh, I guess you just dislike it on principle? Good luck with that.

>3- do not use web bugs, beacons or other trackers

Rule out Analytics software? OK, so far you've whittled out an ideal strategy to create one of the worst-run websites on the web.

"Responsive Web Design" is not even mostly about making websites faster. It's about the way the entire experience scales on different types of devices. Is your website fixed-width or elastic? In either case you're not being Responsive. Does your website serve different imagery depending on the size of the visitor's screen (iPhone vs. 24" Dell monitor)? If not, then you're not being Responsive.

Re:Simple Solution to Faster Web Pages (1)

Lawrence_Bird (67278) | more than 2 years ago | (#38197884)

It should be possible (hmmm... maybe I should patent this?) to locally cache all (or many) of the ads the upstream provider wants you to display. Likewise analytics on those ad views/page impressions can be batched back periodically. Website specific analytics can be hosted locally. As to the social media - is there really a need to provide a facebook login? or a facebook tracker? I suppose some will justify it and perhaps I would have less of any issue (ignoring privacy concerns) if I didn't see so many pages getting stuck while loading facebook.com stuff.

If my website doesn't even work well on a desktop pc it really doesn't matter if it scales up down or sideways. While those points are important they really don't matter if your users leave before the pages are done loading.

Re:Simple Solution to Faster Web Pages (1)

ternarybit (1363339) | more than 2 years ago | (#38203632)

1- do not serve ads from remote servers 2- do not associate with external sites like facebook, etc 3- do not use web bugs, beacons or other trackers

Those three things probably account for 99.9% of the sloth in today's internet

Responsive, in this context, doesn't refer to loading time, but rather the adaptability of a website to respond to a UA's canvas at almost any size and orientation while remaining usable.

Hello? (1)

Lumpy (12016) | more than 2 years ago | (#38196188)

It's called CSS and those of us who paid attention have been using it for years.

it is not hard to make a webpage that looks good on a pc AND a mobile device with CSS.

Keeping that while the idiot client wants you to put in more blinking and scrolling crap is another matter..

CSS Isn't The Whole Answer (1)

cmholm (69081) | more than 2 years ago | (#38196376)

Yes, the mechanism for designing pages that are usable on devices large and small, bandwidth constrained or not, is CSS. But, to the best of my knowledge, there ain't no way to know which tags or class of tag will best render in browser X without a large dose of either browser or capability detection. So, merely replying "CSS" is only giving half of the answer.

Re:CSS Isn't The Whole Answer (1)

cmholm (69081) | more than 2 years ago | (#38196552)

Just to be clear, I'm aware that there's a certain amount of mobile support that can be handled directly in CSS:

> @media only screen and (max-width: 999px)
> @media only screen and (device-width: 768px) and (orientation: landscape)
> @media only screen and (min-device-width: 320px) and (max-device-width: 480px)

etc, but it isn't the end all-be all.

Re:Hello? (3, Insightful)

Eskarel (565631) | more than 2 years ago | (#38197380)

And it doesn't work and never has.

CSS won't allow you to magically show the same content on a 24 inch screen and a 3 inch one because it's about more than layout at that point. You have to completely change what content is shown to make that work, and CSS simply doesn't support that, not even in CSS3. That's not even taking into account the fact that the entire layout and complex CSS will have to be downloaded even if most if it isn't used, or websites which aren't pure text or where layout matters.

Re:Hello? (0)

Anonymous Coward | more than 2 years ago | (#38198852)

The goal is not to "magically show the same content on a 24 inch screen and a 3 inch one" at all. In fact, the best techniques in responsive design is all about improving user experience at both large and small screen sizes--not making it uniform. When you are designing fixed width pages, you have to be really careful not to scrollbar mid-range users (most people don't even care about the low-end users who have been left behind). However, responsive design allows us to design layouts that are much larger and scale down and up with less degradation. For example, what is going to look better on a 2560x1440 resolution? A fixed width website at 978px wide or a responsive, fluid design that maxes out at 1500px or so?

Furthermore, it's entirely possible to design from a mobile-first approach so that mobile devices don't download excess CSS and vice versa. People have a hard time understanding the benefits of responsive design, and I did too until I got an ultra high res monitor and suddenly noticed the web was, well, a very small place. I wish more people would invest in fluid layouts because it's not just our mobile minority that benefits from it and monitor sizes only keep getting bigger.

Indeed, CSS doesn't work (1)

Lazy Jones (8403) | more than 2 years ago | (#38200464)

Especially when mobile devices / their browsers try to camouflage as desktop browsers by a) not using the handheld stylesheet, b) using some arbitrarily large screen dimensions in CSS media queries. Nowdays you have to be very careful with a viewport meta-tag (yes, it's HTML!) in order to get mobile devices to even use your mobile stylesheet...

Re:Hello? (1)

Lumpy (12016) | more than 2 years ago | (#38201190)

IF you are trying to show the same content then you are a fool.

Your backend php/asp shuold already be doing browser detection and simply swapping between mobile and big-ass-screen(tm) css leading to ONE site that services all devices.

Honestly this is fricking Webdesign 101, are you people seriously having trouble with serving comtent to both devicetypes?
I can detect android devices and ios devices and serve up css that makes the webpages look and act like native apps. been doing this for over 2 years now.

And I'm not even a professional webdesigner.

Re:Hello? (1)

Just Some Guy (3352) | more than 2 years ago | (#38203344)

Your backend php/asp shuold already be doing browser detection and simply swapping between mobile and big-ass-screen(tm) css leading to ONE site that services all devices.

The problem there is that your backend server might not (and for large websites probably won't) have full access to the client. Suppose your home page is served by a CDN or other web proxy, or is even just a static page so that it doesn't get overwhelmed by heavy traffic. In those situations, there's not a great way to say "serve this page to mobile visitors and this one to everyone else".

If you can pull it off, there are nice benefits from being able to hand out the same content to everyone along with instructions on how to properly display it on their particular device.

Re:Hello? (1)

Just Some Guy (3352) | more than 2 years ago | (#38203138)

You have to completely change what content is shown to make that work, and CSS simply doesn't support that, not even in CSS3.

Sure it does, to a point. You can write something like:

<p>CSS won't allow you to magically show the same content on a 24 inch screen <a href="/fullarticle" class="shortenedcontent">...</a><span class="fullcontent">and a 3 inch one because it's about more than layout at that point. You have to completely change what content is shown to make that work, and CSS simply doesn't support that, not even in CSS3.</span></p>

And then in your style.css:

.fullcontent { display: none; }
@media only screen and (min-width:481px) {
.fullcontent { display: inline }
.shortenedcontent { display: none }
}

By default, the second half of the post is hidden from visitors and replaced with a clickable link to the full article. Visitors with browsers more than 481px wide - basically everyone not on a smartphone - get to see the whole post because of the media-specific CSS.

That's obviously not the perfect solution for every situation but it'll get you a long way toward the goal.

Re:Hello? (1)

Eskarel (565631) | more than 2 years ago | (#38221572)

For a relatively trivial subset of cases yes, and of course just because display is none doesn't mean it's not downloaded.

The general point being is that for anything non trivial trying to handle your viewers with CSS is needlessly complicated and messy. Generally two pages is a much better way of dealing with things.

Link to a collectible, seems a bit pointless (0)

Anonymous Coward | more than 2 years ago | (#38196810)

The link goes to amazon for someone selling it as a collectible above what seems to be the list price. Maybe Slashdot reads purchased them all. Reviewing a book that cannot be purchased seems a bit silly.

Re:Link to a collectible, seems a bit pointless (1)

MikeKWarren (2467784) | more than 2 years ago | (#38216622)

bad link, big deal...no?

Meh, responsive is useless (0)

Anonymous Coward | more than 2 years ago | (#38201944)

sure responsive is a neat trick, but it won't redraw the context of the data being accessed. People browsing from a phone to a "responsive" still don't get easy access to, say.. a phone number, for example - something very useful to the context of a phone.

Not available on Amazon (1)

ternarybit (1363339) | more than 2 years ago | (#38203660)

It's exclusively available from A Book Apart [abookapart.com] .
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...