On Sun, May 13, 2012 at 6:01 PM, Benjamin Hawkes-Lewis
wrote:
> On Sun, May 13, 2012 at 5:21 PM, Mathew Marquis wrote:
>> When we get ?something new to optimize for,? we start adding that thing
>> going forward. The evolution of media queries?or, say, HTML5?hasn?t led to a
>> need to constantly
On 13 May 2012, at 13:19, Benjamin Hawkes-Lewis
wrote:
> On Sun, May 13, 2012 at 12:26 PM, David Goss wrote:
>> As I understand it, the syntax would
>> have to keep getting extended every time we wanted to test a different
>> property.
>
> It doesn't "tes
On 13 May 2012 10:14, James Graham wrote:
>
>
> On Sun, 13 May 2012, David Goss wrote:
>
>> A common sentiment here seems to be that the two proposed responsive
>> image solutions solve two different use cases:
>>
>> - for serving different resolutions of a
A common sentiment here seems to be that the two proposed responsive
image solutions solve two different use cases:
- for serving different resolutions of a content image
(for bandwidth and dpi)
- for serving different versions of a content image (for art
direction)
...and that neither solution
On 8 February 2012 10:23:02 +, Benjamin Hawkes-Lewis wrote:
> Another option to containment would be referencing: add a @srclist
> attribute on "img" that points to a container of "src"
> elements.
>
> Compare @list and @datalist:
>
>
> http://www.whatwg.org/specs/web-apps/current-work/mu
be5a43-987b-47b3-8245-f11bc8843...@novolo.de>
> Content-Type: text/plain; charset=utf-8
>
> Am 08.02.2012 um 10:43 schrieb Bronislav Klu?ka:
>
>> On 8.2.2012 10:18, David Goss wrote:
>>> On 8 February 2012 07:42, Anselm Hannemann wrote:
>>>> I'd love to hav
On 8 February 2012 07:42, Anselm Hannemann wrote:
> I only have the problem with this "unordered" markup.
> In that case we don't have any wrapper for the alt-text and it would just
> follow as plain on the source-elements.
> We always should have wrappers in my mind, we have this for noscript et
2012/2/8 Kornel Lesiński :
> For DPI/filesize selection I'd prefer something simpler:
>
>
> alternative text
>
Authors want the flexibility of having as few or as many source
elements as they want with whatever media queries they want, not
preset attributes. I don't think this would be adopted
On 7 February 2012 17:11, Boris wrote:
> This is a case of browser vendors (or at least me with my browser
> implementor had on) thinking that sending this sort of information will
> hurt their users' privacy...
Sorry if I'm missing something obvious, but how? I don't think
anyone's asking for th
t images. Hence why it makes
> sense to have the ability to over-ride the alt attribute on each source.
>
> There's nothing to stop us saying that an alt attribute can be declared on
> the default image, and is only over-written if the contains a new alt
> attribute?
>
> -Mat
On 7 February 2012 13:42, Mathew Marquis wrote:
>
> On Tuesday, Feb 7, 2012, at 7:35 AM, David Goss wrote:
>>
>> On 7 February 2012 11:31:15 +0100, Anselm Hannemann wrote:
>>>
>>> This is a good solution except the fallback img element would be twice
>&
On 7 February 2012 11:31:15 +0100, Anselm Hannemann wrote:
Am 07.02.2012 um 11:16 schrieb Matthew Wilcox:
> > To me this makes most sense /from an author perspective/ (I make no
> claims as to how practical this really is):
> >
> >
> >media="min-width:320" />
> >media="min-width:480" />
>
On 26 January 2012 09:21, Markus Ernst wrote:
> Am 25.01.2012 16:39 schrieb Matthew Wilcox:
>
>> It's also worth noting another use case for this being in mark-up and not
>> just server-negotiated rescaling of a single image:
>>
>> Imagine a profile photo on an About page. At large sizes you want
On Tue, 24 Jan 2012 23:26, Ian Hickson wrote:
>
> What's the use case for doing it for images in elements? Typically
> elements are for content images, where you don't usually want to
> adapt anything.
>
> On Tue, 30 Aug 2011, Karl Dubost wrote:
> >
> > And as I explained elsewhere it is not a q
a single form to place
an order which deals with payment for the current order as well as
signup for the account.
David Goss
15 matches
Mail list logo