Skip to main content

Home/ @Publish/ Group items tagged CSS

Rss Feed Group items tagged

Pedro Gonçalves

How To Maintain Hierarchy Through Content Choreography | Smashing Magazine - 0 views

  • Three specifications that we’ll likely find ourselves using in the future are: “Flexbox4,” “Regions5,” “Grid Layout6.”
  • Magic numbers in CSS are best avoided.
  • We need fewer of these HTML containers and more CSS virtual container classes that we can apply to different elements as needed. In other words, instead of this… <div id="container"> <div>Content here</div> <div>Content here</div> <div>Content here</div> </div> … we need more of this: <div class="container">Content here</div> <div class="container">Content here</div> <div class="container">Content here</div>
  • ...5 more annotations...
  • In the latter block, each division might have a different class name or perhaps different additional classes applied. This allows for greater flexibility in rearranging them in the layout. In the first block of code, the three content divisions will always reside inside their parent container.
  • With CSS, we have the ability to rearrange blocks inside a container. We don’t have the ability to break content out of one container and move it inside another container. If you want more mixing of blocks, then you’ll need fewer containers.
  • there are currently far more instances of websites that are dropping columns wholesale
  • Every element is its own unique block and serves as its own container. The page’s main heading is its own contained block. All of the meta information is inside another container directly below it. After that, every paragraph, subheading and image is also its own self-contained block of content. The same goes for anything else that might end up in a post, such as a block quote or code block.
  • a challenge to how we think about structuring our HTML, particularly to how we use containers. Elements can’t move from one container to the next. We can fake it with complex CSS, or we can rewrite the HTML with JavaScript; but, ultimately, if we want to intermix elements, we’re best of using fewer HTML containers to create columns. Instead, we should leave more of our content blocks in their own containers and use CSS to create virtual columns in the layout. This solution doesn’t confine our elements to structural containers and instead enables us to more easily rearrange the elements in different layouts.
Pedro Gonçalves

A Primer on Responsive Design | UX Magazine - 0 views

  • According to IDC, mobile web browsing will soon eclipse desktop browsing in the U.S. and worldwide. This consumption of mobile content isn’t just happening on the go; 93% of people are now using their mobile devices to browse the Web from their homes, according to a study from Google.
  • The main development methodology behind responsive design is the use of media query functionality in CSS3. Media queries target not only certain device types (e.g., Android vs. iPhone), but actually inspect the physical characteristics of the device that renders the page. For example, the code below “asks” the device if its max horizontal resolution is equal to 480px: <link rel="stylesheet" type="text/css", media="screen and (max-device-width: 480px)", href="http://uxmag.com/iphone.css" /> If it is 480px, the device will load iphone.css. If not, the link is ignored. You can also include media queries in CSS as part of an @media rule:
  • a responsive design approach does not involve putting all of your content in front of the reader. Responsive design is about putting the right content in users’ hands according to the context of their interaction.
Pedro Gonçalves

WordPress - Qreator - Premium Wordpress Theme | ThemeForest - 0 views

  •  
    "css3"
Pedro Gonçalves

Standards and benchmarks - 0 views

  • The average top 1,000 web page is 1575 KB.
  • Page growth is a major reason why we keep finding, quarter after quarter, that pages are getting slower. And faster networks are not a cure-all for the challenges of page bloat.
  • According to Akamai’s most recent quarterly State of the Internet report, the global average connection speed among the top 50 internet-using countries is 3.3 Mbps — a 5.2% increase over the previous quarter. But when we’re seeing year-over-year page growth ranging from 45-50%, it’s easy to see that the gap is widening.
  • ...16 more annotations...
  • A whopping 804 KB per page is comprised of images. Three years ago, images comprised just 372 KB of a page’s total payload.
  • images are one of the single greatest impediments to front-end performance. All too often, they’re either in the wrong format or they’re uncompressed or they’re not optimized to load progressively — or all of the above.
  • Today, 38% of pages use Flash, compared to 52% in 2010. This is a good thing. Nothing against Flash, per se, but if Apple has no plans ever to support it, its obsolescence is inevitable in our increasingly mobile-first world.
  • use of custom fonts has exploded — from 1% in 2010 to 33% today.
  • But custom fonts have a dark side: they can incur a significant performance penalty.
  • These days, images on the web have to work hard. They need to be high-res enough to satisfy users with retina displays, and they also need to be small enough in size that they don’t blow your mobile data cap in one fell swoop. Responsive web design attempts to navigate this tricky terrain, with varying degrees of success.
  • Move scripts to the bottom of the page
  • Here at Strangeloop/Radware, we’ve found the opposite. Using WebPagetest, we’ve been testing the same 2,000 top Alexa-ranked ecommerce sites since 2010, and our data tells us that top ecommerce pages have gotten 22% slower in the past year.
  • This quick-and-dirty case study illustrates how network speed doesn’t directly correlate to load time. For example, download bandwidth increases 333% from DSL (1.5Mbps) to cable (5Mbps), yet the performance gain is only 12%.
  • Google published findings, based on Google Analytics data, which suggest that load times have gotten marginally faster for desktop users, and up to 30% faster for mobile users.
  • It’s better to move scripts from the top to as low in the page as possible. One reason is to enable progressive rendering, but another is to achieve greater download parallelization.
  • Make JavaScript and CSS external
  • If users on your site have multiple page views per session and many of your pages re-use the same scripts and stylesheets, you could potentially benefit from cached external files. Pages that have few (perhaps only one) page view per session may find that inlining JavaScript and CSS results in faster end-user response times.
  • Reduce DNS lookups
  • Minify JavaScript
  • In addition to minifying external scripts, you can also minify inlined script blocks. Even if you’re already gzipping your scripts, minifying them will still reduce the size by at least 5%.
Pedro Gonçalves

Google Launches Content Recommendation Engine For Mobile Sites, Powered By Google+ | Te... - 0 views

  • Google’s launch partner for this service is Forbes, but others can implement these recommendations by just adding a single line of code to their mobile sites.
  • These recommendations, Sternberg told me, are based on social recommendations on the site from your friends on Google+ (only if you are signed in, of course), what the story you just read was about, the story’s author and some of Google’s “secret sauce.”
  • The new Google+-based recommendations, interestingly, only appear once a reader slides back up on a page. This, Google’s analytics show, is a pretty good indicator that a user has finished reading a post (even if there is still more text left on the page). The recommendation widget then slides up from the bottom and one extra click brings up more relevant items for the page. The other option is to show the widget after a user scrolls past a configurable CSS entity.
  • ...1 more annotation...
  • Publishers will be able to manage the recommendations widget from their Google+ publisher accounts. From there, they can decide when exactly the widget should appear and manage a list of pages where the widget shouldn’t appear, as well as a list of pages that should never appear in recommendations.
Pedro Gonçalves

Web Developers Brace For the MacBook Pro's Retina Display - 0 views

  • The new laptop, which Apple unveiled last week, already has Web designers and developers trying to figure out how they're going to create sites and Web apps that look good on the new machine without leaving the rest of the Web's population behind.
  • One of the key advantages of these high-resolution displays is their crisp, highly readable rendering of text. That particular buck stops with the Web browsers, which are much more varied on the desktop than on mobile devices. Naturally, Safari supports retina-friendly text, but Chrome is still working on it, and other browsers will presumably follow.
  • For image-heavy sites, swapping out higher-resolution images can have a substantial impact on page load, which in turn affects user experience and even search engine rankings. 
  • ...2 more annotations...
  • To deal with this issue, Web developers can borrow from some of their tried-and-true methods. For years, websites have used browser detection to deliver different CSS stylesheets to different browsers. A similar approach is used to craft responsive designs - when sites load different layouts depending on the device being used to view it. Likewise, this sort of tactic could be used to handle graphics
  • That's exactly what they're doing at O3 World, an interactive agency based in Philadelphia. To account for different screen resolutions, they've begun creating multiple sets of graphics, which are delivered dynamically, depending on the user's screen resolution.
Pedro Gonçalves

In 2014, The Mobile Web Will Die-And Other Mobile Predictions - ReadWrite - 0 views

  • In 2014, the mobile Web will die. That’s right, that bastardized version of the normal Web will crawl into a shallow grave and leave us all in peace. No more websites crippled with horrible “mobile.yourawfulwebsite.com” URLs. No more reading janky websites that display way too much fine print or omit crucial features when viewed on your smartphone or tablet. 
  • The mobile Web will die because the companies that make the engines it ran upon are killing their mobile browsers and replacing them with fully functional versions that run on any device. In 2014, these browsers will be updated to put the final nail in its coffin. In turn, developers will continue to build websites that can work across any screen size. Responsive design (what we do at ReadWrite to make the site look pretty everywhere) will continue to grow in 2014 as people realize that their old websites are losing them a lot of traffic from mobile devices.
  • Location-based consumer apps didn't let me down; as predicted, they remained stagnant this year. Foursquare and its kindred just are not hot anymore, even if Foursquare did just raise a funding round this week.
  • ...2 more annotations...
  • HTML5 Takes Over The Mobile Web
  • Combined with CSS and JavaScript, HTML5 is what the Web will be built on in the future. And it will just be the Web, mobile or otherwise.
1 - 15 of 15
Showing 20 items per page