Re: [whatwg] Features for responsive Web design
On 18 May 2012 22:19, Kornel Lesiński kor...@geekhood.net wrote: On Fri, 18 May 2012 20:24:00 +0100, André Luís andreluis...@gmail.com wrote: If you'd like to see picture proposal succeed, then please help fixing its drawbacks. Make selection and embedding of 2x images easier. Give UA freedom to use cached higher-quality images when it can. Give UA freedom to choose images to minimize bandwidth or maximize quality. Reduce verbosity of most common cases. Thank you, that was helpful. I'm trying to steer the overwhelming amount of messages on the topic both here, online and on that mailing-list (recently joined). This will help me think and mature about some possible theories. I've tried to raise those issues on the Responsive Images group's mailinglist, but got no constructive feedback. People are already spread too thin on this... I myself am struggling to keep up with the current present status of things. :-\ -- André Luís -- regards, Kornel Lesiński
Re: [whatwg] Features for responsive Web design
On 18 May 2012 17:29, Matthew Wilcox m...@matthewwilcox.com wrote: You have to understand that the picture idea was not the result of idle thought. We went through a *lot* of thinking to reach that point, and so it's not actually an attachement to that idea so much as *we know* that idea inside out, what it does, what it doesn't, and why it's like that. We had thought about it from a lot of angles, thrown everything we could at it, and determined that picture was the most robust, familiar, and flexible solution out of half a dozen possibilities - each of which was under similar scrutiny. Then along comes srcset - which has not been subject to the same scrutiny by that group. So *of course* it's getting questioned hard, and *of course* picture is being held as answering the needs best. Until srcset has been properly discussed, inspected, picked apart, and subjected to the same level of scrutiny as picture was, it's not the trusted thing that picture is. Make no mistake; this is not a pride or attachment thing, this is a knowing the reasons thing. I personally don't think picture answers things well enough, nor do I think srcset does. Not for general use cases - but for specific one-off use cases, each has benefits. Absolutely. And from what I read (and I admit not reading the entire archive of messages, but still, prefer to say my piece anyway) the main concern about picture was the potencial verbosity. Instead of trying to solve this issue, it got discarded. There are proposals to deal with the media-query only once to activate a specific page-global profile. It could support both ways: via media attribute in picture or source elements or via a detection made on the head. Anyway, I'll have to re-read the archive of past conversations to be able to formulate a complete proposal. But those efforts anyone of us might take need to be respectfully considered just as srcset has. And not discarded straight away. -- André Luís
Re: [whatwg] microformats, microdata, and custom data attributes
On 19 April 2011 22:36, Tab Atkins Jr. jackalm...@gmail.com wrote: On Tue, Apr 19, 2011 at 2:24 PM, Justin Karneges jus...@affinix.com wrote: On Tuesday 19 April 2011 03:27:30 Rob Crowther wrote: Justin Karneges wrote: Given that it is meant primarily as a data exchange protocol, explicit is better, so I'm preferring Microdata instead of Microformats here. The strength of the Microformats community is in helping to define the vocabulary, that's a different issue from the format you'll use to represent it. Ah, I simply assumed these were two competing approaches. Does this mean Microdata has no community behind it to work on vocabulary? Microdata is a syntax for encoding vocabularies into an HTML page, similar to how class/rel can be a syntax for encoding vocabularies. The vocabularies themselves can be defined largely ignorant of the encoding syntax, as long as the vocab's underlying data-structure ends up being more-or-less tree-based (vocabularies defined for RDF are officially graph-based, but in practice can usually be treated as tree-based). In any case, I think the Person object defined by data-vocabulary.orgshould work for my purposes. But, if I feel the need to invent something new, I can propose it to the Microformats community first if that's the right process. I am quite new to these communities. Hmm.. I'm not really sure we need anything more than simple HTML semantics (given by the spec) and a small microformat/microdata. I'll use q or blockquote in the example. p span class=vcarda href=http://example.com/justin; class=url fnJustin/span said:/span q cite=http://example.com/justin/msg/12345;I agree./q /p or blockquote cite=http://example.com/justin/msg/12345; pI agree./p p class=vcard— a class=url fn href=http://example.com/justin Justin/a/p /blockquote If you prefer microdata: (just the Person bit) p itemscope itemtype=http://data-vocabulary.org/Person; a itemprop=url href=http://example.com/justin; span itemprop=nameJustin/span /a /p If you still think you need a more formal vocabulary, please read: http://microformats.org/wiki/process Cheers, -- André Luís http://id.andr3.net Sounds acceptable. The Microformats community is friendly and open, as far as I've experienced. Have fun! ~TJ
Re: [whatwg] Resolutions meta tag proposal
G'day, since the discussion is more or less trying to find a solution in the markup realm (which I thoroughly support), I'm gonna focus on Roger's proposal of @dpi. I believe the proposal might work. But assuming you might want to target 3x resolutions on all img the size of the document will increase. Like Roger said, it's very important to have this working on a several of ways. 1) content negotiation, at the server level. 2) markup, @dpi or other attribute specifying an alt resource for each resolution ( img src resolutions=?) 3) css, media queries are able to do this.. right? 4) javascript, give access to the document's current resolution in dpi's, under screen.resolution? Although, on point 2, i still prefer the way I suggested earlier, to make img work like the other media tags: video audio, with child source elements that could have either a resolution=96 (per proposal of Roger) attribute or a media query... Anyway, is it still time to have this conversation? Will additions to the spec be considered? Since this Retina (high res screens) business is very new, there isn't much real-world usage to harvest proof of... but is there a process or a set of steps a proposal must go through? -- André Luís http://id.andr3.net/ On 4 July 2010 21:57, Roger Hågensen resca...@emsai.net wrote: On 2010-07-04 14:34, Marques Johansson wrote: Another way about handling this PPI ratio business would be with HTTP 300 multiple choice. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.1 This may not be the best answer for every image on a page, but the first HTML page in a server controlled session could store the PPI ratio setting based on the page the UA chooses and then modify the HTML or content-negotiation setting. A problem with this is that the browsers wouldn't be likely to render a page correctly unless they were modified for this image request yields 300 behavior. I still like something like this for client content negotiation: GET /image/dog HTTP/1.1 Accept: image/*; ppiratio=2 ... HTTP/1.1 200 OK Content-type: image/jpeg ... d...@2x.jpg Apache rewrite rules could even handle this by detecting ppiratio in the Accept header and then looking for a matching images/ratio/2/dog file. If it didn't exist the rewrite would fail resulting in the server responding with images/dog which is suitable if not optimal. This has me thinking Accept: image/*; x=400; y=300 could be attached with any image request based on clients intent for the image. (The HTML said 'width=400 height=300' so I don't need anything better.) The server can ignore this or return something better suited than the 1200x1200 image that it would otherwise return. I still don't have a handle on this retinal / ppi stuff so ppiratio may be the wording. I also like Accept: video/*; kbps=500 for a similar purpose. Again this is negotiation related, and although I'm able to do fancy apache stuff on my site I'd rather not have to. This however takes advantage of CSS http://www.alistapart.com/articles/hiresprinting/ Not exactly ideal, but I think it's the better approach, it just need to be refined and standardized some way. But here's an idea I have that would fit into HTML5. Examples: 1. img src=img/test.png width=512 height=256 dpi=96;;300;image/test300.png work better? (96 dpi is current thus empty ;; while 300 dpi is alternative hence specified. 2. img src=img/test.png width=512 height=256 dpi=300 woould also be valid, indicating that the image is 300 dpi and no alternatives. 3. img src=img/test.png width=512 height=256 dpi=300;image/test300.png same as example 1, 96 dpi default assumed. 4. img src=img/test.png width=512 height=256 dpi=*;image/test.svg 96 dpi default assumed, the * indicate any DPI and in this case it's a vector format. If dpi= or is not specified, then the image should be assumed to be 96dpi, unless the image format has it's own dpi info (JPG support this, but does PNG?) that is. This would make printouts look better, and allows the author to specify displayed size (width and height being logical pixels for non-96 dpi images obviously) High DPI displays would make the browser get the high dpi image instead of the default. The only parts of a site that has issues currently is fixed pixel graphics (and fixed pixel based layout as well I guess), it is only pixel based (bitmapped) images that has issues with scaling, embed video already tend to offer multiple resolutions. So a dpi param for img might just be a nice way to fix the issue. The CSS folks might have to add some support for this too, as well as scripting support. This is just something I came up with right now, but it's at least simple in use which is the important thing I guess. -- Roger Rescator Hågensen. Freelancer - http://EmSai.net/
Re: [whatwg] Resolutions meta tag proposal
On 2 July 2010 14:28, Aral Balkan a...@aralbalkan.com wrote: Hi Marques, I'm an interaction designer/developer, not a rocket scientist. :) A meta tag, I can easily add. If you start talking about HTTP headers, you've lost me. i.e., this is meant to be a pragmatic, easy-to-author solution. I think this point Aral made is very important. This is the kind of stuff that falls under the sphere of the designer/markup author, who might not have control on the webserver configuration. If there is a solution (or solutions), there should exist at least one in the realm of the markup. That's not to say there can't be more than one way of doing this.. content negotiation sounds good, too. I've been musing over this since I read Aral's post... I've been leaning towards a mixture of media queries and a base tag... to specify a different folder for each resolution... but, as it's been pointed out here this would apply to all img tags. This brings me to another question... shouldn't the same exist for all kinds of visual media resources? Thinking img, video, object and possibly iframe. (alt-option 1) Trying to step away from the solution presented, I can only imagine something along the lines of different src attributes for different resolutions: img src=imgs/standard-def.png src-2x=imgs/high-def.png video src=movs/sd.ogv src-2x=movs/hd.ogv But this might be pushing the syntax a bit too further... but it gracefully degrades and can be controlled on a per element basis. (alt-option 2) Or maybe allow an approach similiar to video tag for imgs? img source src= media=..insert media query here.. ? -- André Luís http://id.andr3.net/ On 2 July 2010 18:22, Aryeh Gregor simetrical+...@gmail.com wrote: On Fri, Jul 2, 2010 at 8:39 AM, Aral Balkan a...@aralbalkan.com wrote: I just submitted a proposal for a new meta tag to flag that high-resolution images are available and should be loaded in place of low-resolution ones for users with high-PPI displays (like the new iPhone 4's Retina display). Please see: http://wiki.whatwg.org/wiki/MetaExtensions#Proposals I don't know what the right solution is for this problem (other than use SVG :) ), but I don't think your proposal is workable. Inevitably, some images will be available in different sizes and some not, but your proposed meta tag will affect all images on the page. Also, the author needs to be able to control the names of the resized images to fit their needs -- on a site allowing user-uploaded images, for instance, you might not be able to guarantee that there isn't already a file named flo...@2x.jpg in the directory. The most natural way to do something like this is probably along the lines of content negotiation, but as we all know, that doesn't work well in practice because it's hard for authors to set up. Ideally, you could have the browser include a Resolution: header or something like that, saying what resolution it expects to see, and then the web server should automatically try resizing the image to match (using appropriate caching). But this is too hard to deploy and control. So I don't have any really good ideas.
