| using System; | |
| using System.Collections.Generic; | |
| using System.Text; | |
| using ImageResizer.Plugins; | |
| using ImageResizer.Configuration; | |
| using System.Web; | |
| using System.Threading; | |
| using System.Security.Cryptography; | |
| using ImageResizer.Configuration.Xml; | |
| using System.Web.Hosting; |
| == yield | |
| - if page.meta.includes_editions | |
| - page.meta.includes_editions.split(',').map{ |id| index["plugins/editions/#{id.strip}"] }.to_a.sort_by {|i| i.meta.sort_field}.each do |e| | |
| - if e | |
| h3 Also includes plugins from the | |
| a href="#{e.path}" | |
| = e.heading | |
| - e.edition_plugins.each do |plugin| | |
| li | |
| a(href="#{plugin.path}")= plugin.heading |
| .news | |
| | News | |
| ul.news | |
| - for p in index.posts[0..3] | |
| li | |
| a href=p.path | |
| = p.short_heading || p.heading | |
| li | |
| a href="/blog" | |
| | more... |
| /Users/nathanael/Documents/njcom/hardwired/lib/hardwired/index.rb:127: [BUG] Segmentation fault | |
| ruby 1.9.3p362 (2012-12-25 revision 38607) [x86_64-darwin12.2.0] | |
| -- Control frame information ----------------------------------------------- | |
| c:0089 p:0008 s:0378 b:0378 l:0004f8 d:000377 BLOCK /Users/nathanael/Documents/njcom/hardwired/lib/hardwired/index.rb:127 | |
| c:0088 p:---- s:0374 b:0374 l:000373 d:000373 FINISH | |
| c:0087 p:---- s:0372 b:0372 l:000371 d:000371 CFUNC :each | |
| c:0086 p:0015 s:0369 b:0369 l:0004f8 d:000368 BLOCK /Users/nathanael/Documents/njcom/hardwired/lib/hardwired/index.rb:126 | |
| c:0085 p:---- s:0366 b:0366 l:000365 d:000365 FINISH | |
| c:0084 p:---- s:0364 b:0364 l:0006c0 d:0006c0 CFUNC :each |
What if media queries and breakpoints could stay in the .css file?
What if the image source was chosen based on the min-width, max-width, min-height, and max-height of the <picture> element instead?
Media queries would apply size restrictions to images based on css classes.
The element itself would only be responsible for providing a collection of URLs, described by their size, in pixels, and their mime-type.
| require "zlib" | |
| require "stringio" | |
| require "time" # for Time.httpdate | |
| require 'rack/utils' | |
| module Hardwired | |
| class Deflater | |
| DEFAULT_CONTENT_TYPES = | |
| [ |
| /Users/nathanael/.rvm/gems/ruby-1.9.3-p362@hw/bundler/gems/hardwired-c94a7e28946f/lib/hardwired/index.rb:127: [BUG] Segmentation fault | |
| ruby 1.9.3p362 (2012-12-25 revision 38607) [x86_64-darwin12.2.0] | |
| -- Control frame information ----------------------------------------------- | |
| c:0093 p:0008 s:0403 b:0403 l:0014a8 d:000402 BLOCK /Users/nathanael/.rvm/gems/ruby-1.9.3-p362@hw/bundler/gems/hardwired-c94a7e28946f/lib/hardwired/index.rb:127 | |
| c:0092 p:---- s:0399 b:0399 l:000398 d:000398 FINISH | |
| c:0091 p:---- s:0397 b:0397 l:000396 d:000396 CFUNC :each | |
| c:0090 p:0015 s:0394 b:0394 l:0014a8 d:000393 BLOCK /Users/nathanael/.rvm/gems/ruby-1.9.3-p362@hw/bundler/gems/hardwired-c94a7e28946f/lib/hardwired/index.rb:126 | |
| c:0089 p:---- s:0391 b:0391 l:000390 d:000390 FINISH | |
| c:0088 p:---- s:0389 b:0389 l:001010 d:001010 CFUNC :each |
On Feb. 6th, I published a proposal for a simplified <picture> design, in order to make the element accessible to end-users. After mailing list dicussion, the community was asked for a unified solution that doesn't sacrifice any functionality or performance present in original design.
Without breaking compatibility or usability of the current <picture> design, I believe the that we can also support a simplified, declarative model that focuses on use case 3.1, and is easier for end-users and content management systems to suppport. I introduced the unified proposal on Feb. 27th 2013 via the public-html-comments mailing list, and also notified respimg.
In lieu of duplicating all content from [my original proposal](https://gist.github.com/n
Aliases: /docs/wrappers /docs/contribute Icon: github-alt
Please use the UserVoice forum for ideas and feature requests, so others can vote and comment on your proposals. The ImageResizer project isn't just about resizing. We're Lightroom as a web-service, but with a plugin model so things don't get bloated - and the community is free to innovate.
If your idea doesn't get enough votes to be developed by Imazen, don't despair - If you want to take a shot at implementing it, we'll help you out! We're generally willing to publish community plugins in the /Contrib folder, although you may prefer to host it on your own GitHub repostiory, so we can link to it below.
| { | |
| channel: 1, //Channel ID | |
| originalWidth: 1600, //Original width of the source imagery | |
| originalHeight: 1200, //Original height of the source imagery | |
| displayWidth: 400, //The size of the output imagery (must be correct) | |
| displayHeight: 300, | |
| //Command that are applied to the imagery | |
| commands: { | |
| quality: 90, |
