Balls, that should have read:
"...they go and load the matching resource; which is a 1200px wide image"
i.e., the same as the content column at a viewport width of 1600px.
On 28 May 2012 20:46, Matthew Wilcox wrote:
> On 28 May 2012 20:37, Matthew Wilcox wrote:
>> On 28 Ma
On 28 May 2012 20:37, Matthew Wilcox wrote:
> On 28 May 2012 18:21, Scott Jehl wrote:
>> Matt Wilcox's first two points are fair, though I see them as inconveniences
>> rather than blockers.
>>
>> To his third point, however:
>>
>> I see the suggest
On 28 May 2012 18:21, Scott Jehl wrote:
> Matt Wilcox's first two points are fair, though I see them as inconveniences
> rather than blockers.
>
> To his third point, however:
>
> I see the suggestion mentioned on occasion that content image sizes and
> design breakpoints should be coordinated,
Personally I think it's better than either or srcset alone.
But I don't think it's good enough even so, it still has problems:
* It's verbose (but less-so than ).
* It has two attributes that could easily be confused as doing the
same job. There's little clear logic as to why they're split, from
>> That's true, but the problem isn't so much that as it is that there
>> will be different breakpoints. It's unlikely we'd be working with the
>> same breakpoints, so the one's in the mark-up are all wrong. Leading
>> to incorrect image selection. It's not trivial to revisit all mark-up
>> to corr
On 24 May 2012 09:45, Markus Ernst wrote:
> Am 24.05.2012 10:27 schrieb Matthew Wilcox:
>
>> Excellent, sorry I was not clear on that; this is looking good!
>>
>> I would like to re-iterate that this solution is another which puts
>> design properties into mark-
Excellent, sorry I was not clear on that; this is looking good!
I would like to re-iterate that this solution is another which puts
design properties into mark-up directly, and just like old
and srcset, this means that when it's time to re-design a site an
author is going to have to trawl through
I think this is a good step forward, however nless I am
mis-understanding something (entirely possible given how much has been
going on over this recently) there are problems still...
Resolution of an image and a device is not a guarantee of suitability
of an image at a given physical size. This s
On 19 May 2012 00:37, Kornel Lesiński wrote:
> On Fri, 18 May 2012 23:11:45 +0100, Matthew Wilcox
> wrote:
>
>>> in its current form is unable to support bandwidth-based
>>> negotiation well
>>
>>
>> By all accounts no solution proposed can do thi
>>> Make no mistake; this is not a pride or attachment thing, this is a
>>> knowing the reasons thing. I personally don't think 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. An
You have to understand that the 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 ab
On 18 May 2012 11:17, Kornel Lesiński wrote:
> I think we may be talking past each other, as I don't see how your answers
> address the problems I'm trying to highlight.
Indeed, I'm not debating your points - I accept that it isn't
realistically achievable in HTML/CSS :)
All the last comment wa
On 17 May 2012 19:15, Tab Atkins Jr. wrote:
> On Thu, May 17, 2012 at 11:12 AM, Matthew Wilcox
> wrote:
>>> A few humble thoughts
>>>
>>> -Have the CG recruit an experienced implementor or editor to
>>> participate more or less from the beginning
I also agree with Tab and Jeremy on this one - that makes a lot more
sense to me and removes any ambiguity without being overly verbose.
> I asked:
>> Related question: do we still want to keep this unit-less i.e. ditch the
>> "px" from the examples above? Or, if we're going to use this CSS-like
On 17 May 2012 18:49, Rafael Weinstein wrote:
> It's easy to see how the experience you describe below would be
> frustrating. FWIW, I routinely feel frustration at seemingly wasted
> time.
>
> Unfortunately, it's inescapable that reaching consensus can be
> exhausting, especially via email -- and
On 17 May 2012 17:00, Rafael Weinstein wrote:
> As a UA "implementor", this seem to me to be purely a success story
> for the single reason that it drew so much developer participation.
>
> Regardless of what makes it into the spec, the worst possible outcome
> would be if the developer community
On 17 May 2012 16:07, Tab Atkins Jr. wrote:
> On Thu, May 17, 2012 at 2:18 AM, James Graham wrote:
>> FWIW I think that forming community groups that are limited in scope to
>> gathering and distilling the relevant use cases could be a functional way of
>> working. For example if, in this case, p
>> WHATWG does not exist to be a closed society.
>
> (Is this a joke? This is probably the most open and approachable spec
> development community in existance today.)
"This is probably the best square wheel there is today" does not make
it a good wheel, even if it's better than all the other squ
>> That particular solution is, to my mind, the most flexible and useful
>> implementation I've seen, because it's really about breakpoint
>> management and abstraction - which is what all responsive elements
>> need in order to work together well and be future-friendly.
>>
>> It does, no doubt, ha
Cheers for that feedback Andy - it is indeed a complicated issue with
much more nuance than I think many people (myself included) would have
expected. I still think there's a technical solution there, but as you
say - it's making that solution reliable enough to be worth it. The
problem really is "
On 17 May 2012 11:05, Kornel Lesiński wrote:
> On Wed, 16 May 2012 21:11:41 +0100, Matthew Wilcox
> wrote:
>
>>> What solution do you have in mind that would let you add a 'tv'
>>> breakpoint site-wide for all images that have been prepared for it, without
&g
> The solution I've seen proposed[1] only aliases media query content, and
> works only on a per-page basis, so it doesn't allow automatic addition of a
> new image size site-wide, since you have to insert new into every
> anyway.
That is not true. With that particular solution you would never a
@Tab - yes I do remember, sorry. I'm being a bloody idiot.
On 16 May 2012 20:12, Jacob Mather wrote:
> Maybe this is the better question:
>
> Why does the pre-loader matter so much?
>
> Basing the selected image off of browser width is inherently
> backwards. The content should be informed by the layout, not by the
> browser.
>
I do agree with you (it's
On 16 May 2012 20:10, James Graham wrote:
> On Wed, 16 May 2012, Matthew Wilcox wrote:
>
>> First off I know that a number of people say this is not possible. I
>> am not wanting to argue this because I don't have the knowledge to
>> argue it - but I do want to under
On 16 May 2012 20:04, Tab Atkins Jr. wrote:
> On Wed, May 16, 2012 at 11:55 AM, Matthew Wilcox
> wrote:
>> On 16 May 2012 19:47, Tab Atkins Jr. wrote:
>>> On Wed, May 16, 2012 at 5:58 AM, Matthew Wilcox
>>> wrote:
>>>> Also, srcset does not abstr
Ok, so really it's an efficiency of authoring problem; before I just
didn't get how it'd be any different to a viewport width from the
perspective of an author.
That said, when coupled with viewport responses... yeah, that could
get complicated to author. Essentially each bandwidth bracket would b
On 16 May 2012 19:47, Tab Atkins Jr. wrote:
> On Wed, May 16, 2012 at 5:58 AM, Matthew Wilcox
> wrote:
>> Also, srcset does not abstract the control points away from the image
>> itself. I have already been over why this is a problem and
>> future-unfriendly. Breakpoin
First off I know that a number of people say this is not possible. I
am not wanting to argue this because I don't have the knowledge to
argue it - but I do want to understand why, and currently I do not.
Please also remember that I can only see this from an authors
perspective as I'm ignorant of th
> I kinda like the
> syntax in the spec draft, it's short and sweet. And obvious when you
> know.
Everything is obvious when you know. The challenge is making it
obvious when you don't. Which is why using familiar patters is good.
Which is why picture had a strong advantage in that regard.
> Peop
Cheers :)
On 16 May 2012 15:05, Mike Taylor wrote:
> On Wed, 16 May 2012 08:40:46 -0500, Matthew Wilcox
> wrote:
>
>> What's the actual WHATWG proscribed format for conducting conversations in
>> email
>> format?
>
>
> See http://wiki.whatwg.org/wiki
complain when
replies are in-line in the style you request, other people complain
unless the whole thread is included verbatim in any reply. What's the
actual WHATWG proscribed format for conducting conversations in email
format?
>
> Matthew Wilcox wrote:
>>
>> If there was a
If there was a way to do this in JS, we'd have found it. Every time we
run up against the pre-fetch problem. In fact, it is only the
pre-fetch problem that causes responsive images to be an issue at all.
It'd be trivial to fix with JS otherwise.
Also, i don't think non-pixel based layouts can be e
aking
response points directly into an element will be hell to work with in
any re-design.
-Matt
On 16 May 2012 13:58, Matthew Wilcox wrote:
> Also, srcset does not abstract the control points away from the image
> itself. I have already been over why this is a problem and
> fut
breakpoints, and that would mean having
to revisit and edit every image that's had srcset applied - unless I
am missing something (which given the last day or two, I may well be).
-Matt
On 16 May 2012 13:55, Matthew Wilcox wrote:
> Chalk me up as another making that mistake. Properties on
Chalk me up as another making that mistake. Properties on elements
usually describe a property of the element. Not a property of
something else (like the viewport).
I'm happier than I was about srcset - but why does the spec assume
pixels? Or does it?
Use case: design breakpoints can and often ar
So wrap an image in SVG? I don't see this as being very clean.
On 16 May 2012 10:49, Aldrik Dunbar wrote:
>> As far as I'm aware SVG does not tackle the primary type of image an
>> element diaplsys - photographic, non-vector images.
>
> SVG has a number of ways to include raster graphics image
Am i right in believing that the srcset attribute are limited to
pixels? A unit that's dying out in all responsive designs? Is it
extensible to em, % etc? Because that's what's used.
On 16 May 2012 08:39, Chris Heilmann wrote:
> On 16/05/2012 00:23, Kornel Lesiński wrote:
>>
>> On Tue, 15 May 201
As far as I'm aware SVG does not tackle the primary type of image an
element diaplsys - photographic, non-vector images. SVG is not
applicable for enough uses.
-Matt
On 16 May 2012 07:17, Tab Atkins Jr. wrote:
> On Tue, May 15, 2012 at 6:23 PM, Aldrik Dunbar wrote:
>> Hi there,
>>
>> Adding a
that is why authors
feel it's flawed. It doesn't do what we need, and never can because
srcset is based on the assumptin that a UA can somehow pick an
appropriate resource to load - when it can't possibly know about the
authors use of that resource at that time.
-Matt
On 15 May
Um, the fact of the matter is we don't want to ensure they have the
same ratio. It is exactly why we want to swap images sometimes - the
aspect ratio no longer fits the design being applied at the given
breakpoint.
On 15 May 2012 18:48, Jason Grigsby wrote:
> On May 15, 2012, at 9:54 AM, Tab At
would
> not work for this?
>
>
>
> Shane Hudson (Website Developer - www.ShaneHudson.net)
>
> 07794746595
>
> @ShaneHudson / +Shane Hudson
>
> On Tuesday, 15 May 2012 at 11:22, Matthew Wilcox wrote:
>
> I do not see much potent
ready "indirect" - to the extent of being in a different
file entirely.
-Matt
On 15 May 2012 11:13, Matthew Wilcox wrote:
> Constraints on where assets are placed and named? I do not follow your
> reasoning here: You put them in the folder that's used for that design
> breakp
If it works for authors using CSS, why should it not also work for
setting image paths?
-Matt
On 15 May 2012 10:57, Anne van Kesteren wrote:
> On Tue, May 15, 2012 at 11:38 AM, Matthew Wilcox
> wrote:
>> Please, have you taken a look at the latest idea?
>>
>> http://
08:28, Ian Hickson wrote:
> On Wed, 25 Jan 2012, Matthew Wilcox wrote:
>> On 24 January 2012 23:26, Ian Hickson wrote:
>> > On Wed, 24 Aug 2011, Anselm Hannemann - Novolo Designagentur wrote:
>> > >
>> > > As we now have the possibility of creating fluid a
4, 2012 at 9:31 AM, Matthew Wilcox
> wrote:
>> All good points, thanks. Sorry I'd missed you saying
All good points, thanks. Sorry I'd missed you saying
2
)
I had presumed that should multiple cases match the browser would
simply uses the last matching one. There's already a polyfil in JS
that does exactly that: http://jsbin.com/3/ecifaf/latest/
On 14 May 2012 15:50, Tab Atkins Jr. wrote:
> On Mon, May 14, 2012 at 10:55 AM, Matthe
, 2012 at 10:55 AM, Matthew Wilcox
> wrote:
>> have any of you seen this proposal for an alternative solution to the
>> problem?
>>
>> http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
>>
>> I like t
Hi all,
have any of you seen this proposal for an alternative solution to the problem?
http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
I like the general idea and from an author perspective this seems
great; but I know nothing of the brow
On 6 February 2012 19:24, Irakli Nadareishvili wrote:
> Boris,
>
> if you don't mind me saying it, I am afraid you may be missing the point of
> this request. In Responsive Web Design, device capabilities are used in a
> high-level fashion to determine a class of the device: smartphone, tablet,
ems necessary to convince people that an actual
>> issue exists and to discuss potential solutions somewhere. So an honest and
>> humble question, if that doesn’t happen here, where does it happen?
>>
>> -Jason
>
> On Thu, Feb 9, 2012 at 11:36 AM, Matthew Wilcox
>
+1 to everything Jason Grigsby just said.
If not here, where? If not with you, with who? We've been doing this
publicly for months and months...
> > > And, screen size is useful when understood to mean "CSS Pixels".
> > > Because that's what a browser renders. If a device has a screen 1900px
> > > CSS px wide, you know you never need send anything larger.
> > It's getting in the way, and it's certainly been a strong topic.
> I know that i
x27;s client)
isn't going to pay for it.
On 7 February 2012 21:19, Charles Pritchard wrote:
> On 2/7/2012 1:14 PM, Matthew Wilcox wrote:
>>>
>>> > Also, I am writing this on a laptop via a throttled mobile connection.
>>
>> It'd be nice if
7 February 2012 20:24, Charles Pritchard wrote:
> On 2/7/2012 11:52 AM, Matthew Wilcox wrote:
>>
>> On 7 February 2012 17:59, Boris Zbarsky wrote:
>>
>>> On 2/7/12 12:32 PM, Matthew Wilcox wrote:
>>> In what circumstances might this cause breakages?
>>
On 7 February 2012 20:05, Nils Dagsson Moskopp
wrote:
> Matthew Wilcox schrieb am Tue, 7 Feb 2012
> 19:38:31 +:
>
>> Can we not turn this into an option in the same way browsers handle
>> requests to get the users location? With configuration too?
>>
>> Allow
On 7 Feb 2012, at 20:19, Boris Zbarsky wrote:
On 2/7/12 2:52 PM, Matthew Wilcox wrote:
Reporting more information about the user's hardware and software to
the server allows better fingerprinting and hence tracking. See
https://www.eff.org/deeplinks/__2010/01/primer-inform
Thanks again, you make some good points :)
More responses inline...
On 7 February 2012 17:59, Boris Zbarsky wrote:
> On 2/7/12 12:32 PM, Matthew Wilcox wrote:
>
>>This is a case of browser vendors (or at least me with my browser
>>implementor had on) thinking that se
see my:
screen size
connection speed
…
On 7 February 2012 22:45, Mike Taylor wrote:
> On Tue, 07 Feb 2012 11:32:23 -0600, Matthew Wilcox
> wrote:
>
> , will cause their users to get more broken pages (which is what happens
>>> in many cases with browser sniffing righ
Thanks for the feedback :)
I've replied inline, but please be aware that I don't have a browser-vendor
hat to put on so some of my questions may well be a bit naive (for which I
apologise in advance)
On 7 February 2012 17:11, Boris Zbarsky wrote:
> On 2/7/12 9:13 AM, Matthew
proof data exposed.
On 7 February 2012 16:46, Charles McCathieNevile wrote:
> On Tue, 07 Feb 2012 15:13:03 +0100, Matthew Wilcox
> wrote:
>
> Personally, I think the issue of adapting resources to client
>> capabilities is here to stay.
>>
>
> For sure, although th
of not allowing alt over-riding in that it forces
the alt to be applicable to all sources which then strengthens the vibe
that the images, although different, should have the same semantics.
On 7 February 2012 14:59, David Goss wrote:
> On 7 February 2012 14:00, Matthew Wilcox wrote:
> &
the choice of restricting SPDY to HTTP's viable capabilities which is
the cause of a potential veto of this.
:)
On 7 February 2012 13:34, Henri Sivonen wrote:
> On Mon, Feb 6, 2012 at 5:52 PM, Matthew Wilcox
> wrote:
> > Also, as indicated, with SPDY this is much much less
PS: I am a strong believer that we need both a server-side and client-side
solution to this problem of adaptive media. They solve different aspects of
what seem superficially the same things :)
>
> 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):
>> >
>> &
; http://www.alistapart.com/comments/responsive-images-how-they-almost-worked-and-what-we-need/P40/#41
>
> Am 07.02.2012 um 11:34 schrieb Matthew Wilcox:
>
> Can you clarify why the image would be loaded twice?
>
> Can we not, as part of the logic for the element, say that
2012 10:31, Anselm Hannemann wrote:
> Am 07.02.2012 um 11:16 schrieb Matthew Wilcox:
>
> 2012/2/7 Anselm Hannemann – Novolo Designagentur
>
>> Ashley,
>>
>> so you think about the element attributes like I proposed?
>> > media-m="(min-device-width:6
@Mathew Marquis - that was a good article, I was so pleased to see the
thinking behind it getting some attention at last! I've been trying to push
this idea since launching adaptive-images.com , and a number of people have
come up with the same client-side quasi-solution independently. Bruce
Lawson
On 7 February 2012 00:12, Jason Grigsby wrote:
> I agree that this is a problem. I’ve spent far too much time trying to
> find solutions for images in responsive designs and none that I reviewed
> work. (research at http://cloudfour.com/responsive-imgs-part-2).
>
Seconded, my work has been http:
em from blocking my onload. Works fine.
>
>
> -Charles
>
>
>
> On Feb 6, 2012, at 12:16 PM, Matthew Wilcox
> wrote:
>
> >>
> >> Scripting on the client side for the purposes of content negotiation
> *does
> >> not work*
> >>
> >
PS, sorry all if some mails here are duplicates. I am fighting my mail
client which keeps sending mail from the wrong account, which is then
rejected by the list.
On 6 February 2012 20:17, Matthew Wilcox wrote:
> On 6 Feb 2012, at 19:19, Bjartur Thorlacius wrote:
>
> > On Mon, 06 Fe
On 6 Feb 2012, at 19:19, Bjartur Thorlacius wrote:
> On Mon, 06 Feb 2012 18:58:00 -, Boris Zbarsky
wrote:
>> Again, it's not constant in the terms that the page sees, which are CSS
pixels, not device pixels.
>>
> We're discussing HTTP here, so the content might just as well be raster
bitmaps.
> On 2/6/12 1:55 PM, Irakli Nadareishvili wrote:
>> Many thanks to everybody who has responded and for a lively and a
productive discussion!
>>
>> Quick clarification: the proposal is to include *device* capabilities in
the HTTP headers, so when we say "screen width and height" we mean device
scree
>
> Scripting on the client side for the purposes of content negotiation *does
> not work*
>
Please, understand this. Because browsers pre-fetch as soon as a node is
> created there can be no client-side solution to this issue with the current
> HTML/JS specifications and browser behaviour. The ima
s up
re-flowing and re-loading assets just because you've increased the window
size.
On 6 February 2012 16:00, Boris Zbarsky wrote:
> On 2/6/12 10:52 AM, Matthew Wilcox wrote:
>
>> 1) client asks for spdy://website.com
>> 2) server responds with content and adds a "requ
future requests on the domain.
4) server can push any amended content from 2) over SPDY without another
request (because SPDY can).
This way there are no additional overheads unless the server has requested
them specifically.
-Matt
On 6 February 2012 15:38, Charles McCathieNevile wrote:
> On
al to have a class appended to the article. When would you
want this as pure HTML that's not been parsed by some form of CMS?
On 26 January 2012 21:43, Matthew Wilcox wrote:
>
> On 26 Jan 2012, at 20:47, Bjartur Thorlacius wrote:
>
> > Þann fim 26.jan 2012 14:48, skrifaði Mat
What's wrong with using a class on the to identify the author
stylistically? It's already identified semantically by having their name in
the itself, right (presumably in a too)?
On 26 January 2012 13:57, Bjartur Thorlacius wrote:
> On Wed, 25 Jan 2012 22:26:31 -, Ian Hickson wrote:
>
>>
> Am 25.01.2012 15:07 schrieb Matthew Wilcox:
>
> In fact, please just read the blog post Bruce Lawson (Opera Software)
>> made summarising the last few months of effort on this, and his proposal
>> for a mark-up level solution (which I'm in broad support of, though the
Ugh, my Gmail keeps sending mail from the wrong address, let me try again:
...
In fact, please just read the blog post Bruce Lawson (Opera Software)
made summarising the last few months of effort on this, and his proposal
for a mark-up level solution (which I'm in broad support of, though there
a
Please see responses inline:
On 24 January 2012 23:26, Ian Hickson wrote:
> On Wed, 24 Aug 2011, Anselm Hannemann - Novolo Designagentur wrote:
> >
> > As we now have the possibility of creating fluid and responsive layouts
> > in several ways we have a problem with images.
> >
> > There's curre
82 matches
Mail list logo
