[WSG] Re: WSG Digest
my apologies - the 'context' i referred to is fully out of the hands of the designer - it is the browsing environment, determined via a mixture of user-agent information, feature detection and media queries... On 16 September 2012 16:54, wsg@webstandardsgroup.org wrote: * WEB STANDARDS GROUP MAIL LIST DIGEST * From: Mathew Robertson mathew.blair.robert...@gmail.com Date: Sun, 16 Sep 2012 12:01:42 +1000 Subject: Re: [WSG] Re: WSG Digest Part of the img vs picture discussion, has been to define what features are actually required of this element. Primarily this has come down to: a) responsive handling of bandwidth vs image-quality (aka bandwidth vs file-size) b) pixel density of display devices c) art direction [ Did I miss any? ] Breaking them down: a) bandwidth is completely out of control of the website designer... (eg: 3G bandwidth varies x10 with time) so there is next to no reason for markup (HTML or CSS) to be related to bandwidth. If the designer chose to use JPEG2000, SVG, HDF or some other tileable/scalable format, then changes the scope somewhat, as the browser could implement range requests to the webserver to indicate which block of data would suit its currently available bandwidth. b) Pixel density depends completely on the target device... again outside of the designers control (unless you want to design for every version of every device in existence). And again the best a designer can do is offer multiple images. In which case, srcset seems like a nice way to go, as it leverage's an existing element thus allowing backwards compatibility. c) The art-direction aspect can be solved using variations of clip(...) combined with range-requests. An extra mention... the media: max-width variations are really not all that useful (unless you are targeting an exact screen size + density)... my eyes work well enough so that I can read small text, so would happily like to use tablet-width layouts on a small screen. The idea of context would seem appropriate... just need to remember that some of that context is not in the hands of the designer. Just my $0.02... cheers, Mathew Robertson On 14 September 2012 17:03, Dominic Hey dominic@gmail.com wrote: To paraphrase your own words.. if an img src=... is descriptive of the target image then srcset would be descriptive of the *set* of target images, no styling information there. Where I would be more inclined to agree with you would be the media attribute, however if you abstract the essence of a media query it is not, in itself, concerned with styling. It is a conditional test. Perhaps we need a fourth element - context - to join the separate channels of content, behaviour and appearance? On 14 September 2012 16:43, wsg@webstandardsgroup.org wrote: * WEB STANDARDS GROUP MAIL LIST DIGEST * From: Mathew Robertson mathew.blair.robert...@gmail.com Date: Fri, 14 Sep 2012 10:53:34 +1000 Subject: responsive images In this week's links for light reading, there is a reference to responsive images, eg: http://www.netmagazine.com/features/road-responsive-images I'd be interested to hear this lists' opinion on the proposed syntax. To me this screams of putting styling information, into the document. For comparison, we now use media queries to change font sizes and element locations, based on viewport size and/or direction. I would have expected responsive images to be implemented in a similar manner, not with new html tags. In other words, an img src=... is descriptive of the target image, and we add alt-attributes to describe it as such. Simply showing a higher quality image of the same thing, shouldn't change the document structure. Thoughts? Mathew Robertson ** Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** ** Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org
[WSG] Re: WSG Digest
To paraphrase your own words.. if an img src=... is descriptive of the target image then srcset would be descriptive of the *set* of target images, no styling information there. Where I would be more inclined to agree with you would be the media attribute, however if you abstract the essence of a media query it is not, in itself, concerned with styling. It is a conditional test. Perhaps we need a fourth element - context - to join the separate channels of content, behaviour and appearance? On 14 September 2012 16:43, wsg@webstandardsgroup.org wrote: * WEB STANDARDS GROUP MAIL LIST DIGEST * From: Mathew Robertson mathew.blair.robert...@gmail.com Date: Fri, 14 Sep 2012 10:53:34 +1000 Subject: responsive images In this week's links for light reading, there is a reference to responsive images, eg: http://www.netmagazine.com/features/road-responsive-images I'd be interested to hear this lists' opinion on the proposed syntax. To me this screams of putting styling information, into the document. For comparison, we now use media queries to change font sizes and element locations, based on viewport size and/or direction. I would have expected responsive images to be implemented in a similar manner, not with new html tags. In other words, an img src=... is descriptive of the target image, and we add alt-attributes to describe it as such. Simply showing a higher quality image of the same thing, shouldn't change the document structure. Thoughts? Mathew Robertson ** Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] Re: WSG Digest
joining the party a little late here.. unless i have misunderstood things here this is a perfect situation to employ XSLT ( http://en.wikipedia.org/wiki/XSLT). you can assign whatever attributes you require to the XML and then use XSLT to have the browser render the file as XHTML. On 2 August 2012 10:38, wsg@webstandardsgroup.org wrote: * WEB STANDARDS GROUP MAIL LIST DIGEST * From: Mathew Robertson mathew.blair.robert...@gmail.com Date: Wed, 1 Aug 2012 09:57:54 +1000 Subject: Re: [WSG] XHTML5 polyglot markup and WAI-ARIA, is there a valid way? Hi Isabel, It sounds like you might be confusing/mixing your requirements... from the limited information you have provided, this sounds like perfect candidate to generate two separate files ie: HTML already has accessibility built in, and you get the XML file contain exactly what you require. regards, Mathew Robertson On 1 August 2012 09:29, Isabel Santos unboun...@gmail.com wrote: Hi Rob, thank you, and sorry for the delayed answer. The need for xml comes from the site being a web application for an academic work. The idea is to generate xml both to the site and for exchange purposes. I could generate both xml and html but that isn't very elegant, and would not optimise the resources. In fact, accessibility, validity, design and usability are my own concerns, they aren't part of the work, won't be evaluated, and are taking more time then they should. Anyway, as long as it is possible to do, the more difficult a work, the more one learns. I gess I've lost a good part of the WAI-ARIA development history, it's kind of hard to understand the excessive and aparently arbitrary strictness of xhtml in regards to ARIA. regards, isabel On Mon, Jul 30, 2012 at 10:56 AM, Rob Crowther robe...@boogdesign.com wrote: What XML content do you need to include? If you just stick to regular HTML5 then all the ARIA stuff is valid (with some sanity restrictions) and you won't have to work around the strict parsing: http://www.whatwg.org/specs/**web-apps/current-work/** multipage/elements.html#wai-**aria http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#wai-aria XML elements will be parsed into the HTML5 document tree, albeit slightly differently to how an XML document would be parsed, but maybe close enough for your purposes depending on what XML you'll be including. Rob *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *** * From: Rob Crowther robe...@boogdesign.com Date: Wed, 01 Aug 2012 02:01:34 +0100 Subject: Re: [WSG] XHTML5 polyglot markup and WAI-ARIA, is there a valid way? On 01/08/12 00:29, Isabel Santos wrote: I could generate both xml and html but that isn't very elegant, and would not optimise the resources. Unless you serve the XHTML files with a MIME type of application/xml or application/xhtml+xml, which will break things in IE9, the browser will treat all the content as HTML anyway. This is precisely because of XHTML's arbitrary strictness. http://wiki.whatwg.org/wiki/HTML_vs._XHTML#Differences_Between_HTML_and_XHTML Rob ** Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] Re: WSG Digest
Hi Grant, You could have a dedicated mobile site (using a sub-domain and server-side client detection, for instance) with zero regard paid to accessibility *or*standards. Responsive design (using media queries, for instance) follow the DRY principle - Don't Repeat Yourself. Rather than think about mobiles/desktops I prefer to think of responsive design as catering to any number of devices (think forward a few years to when we see 3G/web browsers built in to car dashboards etc., or as the browsers built into televisions improve). For a lot of websites (e.g. Skysports.com) the cost to integrate responsive design into their existing templating system far exceeds the cost of creating a dedicated mobile sub-domain. There should still only be one data source however, for both implementations. Regards, Dominic On 16 May 2012 13:48, wsg@webstandardsgroup.org wrote: * WEB STANDARDS GROUP MAIL LIST DIGEST * From: grant_malcolm_bai...@westnet.com.au Date: Wed, 16 May 2012 10:43:03 +0800 (WST) Subject: Mobile sites Hello, I was wondering whether having a dedicated mobile site represents an improvement with regard to accessibility and standards, or whether it is acceptable to have a single site that is adaptable to different screen widths (e.g. by means of CSS media queries). Of course, setting up a separate mobile site requires additional work and therefore expense. I would be grateful for comments. Thank you and regards, Grant Bailey ** Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
[WSG] Re: WSG Digest
http://www.w3schools.com/css/pr_text_letter-spacing.asp On Sep 14, 2010 8:26pm, wsg@webstandardsgroup.org wrote: * WEB STANDARDS GROUP MAIL LIST DIGEST * From: Lyn Smith l...@westernwebdesign.com.au Date: Tue, 14 Sep 2010 17:18:46 +0800 Subject: Fonts in MS Publisher compared to online I have a client who is very precise in what he wants. He sent me a draft in Publisher which I transformed into a website. The font for the header text (site title) is Times New Roman. The problem is that it looks completely different online to what it does in Publisher. Publisher renders it very narrow. Online it looks chunkier even though it is just normal weight, not bold. It is 2.5ems - I tried reducing the size but it did not reduce the chunkiness. According to Publisher, the style is Normal, 10pt, Main(Black), Kerning 14pt,Left, Line Spacing 1sp. As far as I can see, there is nothing wrong with the way it looks online at all - but it is not what he wants. He wants narrow. Is there a way of making the font narrower - short of making it an image - or is there an explanation I can give him of why it looks different online? Thanks. -- Lyn Smith www.westernwebdesign.com.au Affordable website design Perth WA ** Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ** *** List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org ***
