Comments (16)
For this Use Case it might be worth referencing RFC 2295 which provides a technical overview of content negotiation.
from ri-usecases.
@ShaneHudson thanks for the link. We should probably also check out HTTPBis as it's more updated.
from ri-usecases.
@ShaneHudson so, after thinking about it, I think it would be safer just to point to the HTTP spec.
from ri-usecases.
FYI, I've rewritten one of the requirements:
The solution MUST NOT require server-side processing or HTTP content negotiation.
I'll start on the use case now.
from ri-usecases.
Also, I'd like to bring up the eBooks/ePub use case. EPUB closely tracks (X)HTML development, and has historically avoided 'extending' HTML markup specifications, although it has been freer with CSS.
By nature, an offline HTML file/archive or EPUB book doesn't support HTTP negotiation. Most offline readers do not support javascript either.
However, they are both in a challenging position when it comes to images, as readers often only support one image format (until recently, only PNG was supported by many readers), and many variants are needed to support the variety of screen types (e-ink, LCD) and resolutions (Think Kindle/Nook on iPad 3 vs Android).
I know I'm describing two different use cases here (offline HTML and EPUB), but they do share a lot. A good solution to responsive images will be of great benefit to both situations.
from ri-usecases.
- RFC 2295 has one major flaw: it imposes a huge latency penalty by requiring an extra
list response
in the workflow. - User-Agent techniques are a dead-end, and cannot adapt to dynamic use cases
- Client-side techniques have similar penalty (or worse) as RFC 2295
A work-in-progress, Client-Hints: https://docs.google.com/document/d/1xCtGvPbvVLacg45MWdAlLBnuWa7sJM1cEk1lI6nv--c/edit#
I would relax the language for "MUST NOT require server-side processing". The server is the origin, and given more information, it can do intelligent things and work well with intermediate caches. Granted, the Client-Hints proposal is independent of, and not limited to responsive images use cases.
from ri-usecases.
The key word here is "require". Maybe the language can be clearer in this respect, but the point here is that a solution that requires server-side processing without the possibility of client-side negotiation is significantly less useful for people who are less handy on the server side than you or I, or who lack the budget to scale a server-side solution the way Google or Adobe can.
I don't think this language precludes using the server where appropriate, as an enhancement over the baseline spec.
On Oct 25, 2012, at 1:43 PM, Ilya Grigorik [email protected] wrote:
RFC 2295 has one major flaw: it imposes a huge latency penalty by requiring an extra list response in the workflow. - User-Agent techniques are a dead-end, and cannot adapt to dynamic use cases
Client-side techniques have similar penalty (or worse) as RFC 2295
A work-in-progress, Client-Hints: https://docs.google.com/document/d/1xCtGvPbvVLacg45MWdAlLBnuWa7sJM1cEk1lI6nv--c/edit#I would relax the language for "MUST NOT require server-side processing". The server is the origin, and given more information, it can do intelligent things and work well with intermediate caches. Granted, the Client-Hints proposal is independent of, and not limited to responsive images use cases.
—
Reply to this email directly or view it on GitHub.
from ri-usecases.
Agreed, the wording could probably be a little better (and agree with @ddemaree). I'm open to suggestions.
from ri-usecases.
@ddemaree I want to dispel the myth that only Google or Adobe would be able to do server-side adaption. Just like srcset defines a well-known "2x" filename, nothing stops us from defining multiple filenames (via a convention, a configuration flag, or similar), for other variables: name-lw.jpeg vs. name-hw.jpeg for low-bandwidth, vs high-bandwidth. (may not be the best example, but you get the point). These files can be created at build / design time, and live on the server side-by-side. Nothing new here.
Re, language: right, I'm with you guys. I just want to make sure that when people read these use cases, they don't rule out the server-side adaption entirely. If the server supports it - great. But I agree that it can't be a required component.
Perhaps something like: The solution MUST NOT require server-side processing, but server-side adaptation may be used where available through or [HTTP11] content negotiation, or similar techniques.
from ri-usecases.
The solution MUST NOT require server-side processing, but server-side adaptation may be used where available through or [HTTP11] content negotiation, or similar techniques.
That seems fair to me. Would it make sense to expand it to something like:
The solution MUST NOT require server-side processing or HTTP content negotiation, but SHOULD NOT preclude the use of server-side adaptation and content negotiation.
Spec-writing is way outside of my wheelhouse; I’m not sure if the “SHOULD NOT” is appropriate here—just throwing that one out there.
from ri-usecases.
How about:
The solution MUST NOT require server-side processing to work. However, if required, server-side adaptation can still be done through [HTTP11] content negotiation or similar techniques.
@Wilto, pro tip: in spec land, you can't ever have a MUST followed by a SHOULD.
from ri-usecases.
See that? I learned something today.
The solution MUST NOT require server-side processing to work. However, if required, server-side adaptation can still be done through [HTTP11] content negotiation or similar techniques.
Sold.
from ri-usecases.
Ok, added it to the spec. Have not committed it yet.
@ddemaree, sorry I have not actually been able to articulate a full use case section around this yet. We were prioritising the launch of responsiveimages.org and preparing for presenting at TPAC next week :( However, it might be sufficient to just have the requirement and not a full use case description: content negotiation is understood to be a cataclysmic failure.
from ri-usecases.
@marcoscaceres @Wilto looks good, thanks for the quick turnaround!
from ri-usecases.
I am very glad to see the Content Negotiation in like this. And very glad to learn about Client Hints, those are what I've been wanting for a long while :)
from ri-usecases.
As we added the requirement, I'm closing this bug. Please reopen if you think we need to add anything else.
from ri-usecases.
Related Issues (20)
- XSS attack <script>console.warm('pwned')</script> HOT 8
- File bugs at the W3C against individual use cases. HOT 4
- Find out what we need to do to go to W3C FPWD HOT 10
- Get commitments from CG members HOT 5
- Art direction use case description should be more than cropping HOT 2
- Resolution switching illustration is misleading HOT 4
- Clarify explanatory statement about WebP/Jpeg vs PNG. HOT 1
- Add additional solution requirements HOT 4
- Add a "support preloading" use-case HOT 7
- Modify the relative units section HOT 3
- Mention relying color alone is an accessibility issue HOT 7
- equation images HOT 10
- Sentence mistake in 4. Requirements -> point 10
- Section 1.1 still has src-N listed as 'in-development' solution HOT 2
- Invented word HOT 3
- Add an "invisible images" use-case HOT 2
- Adapt object-fit, object-position by matching source HOT 6
- Add a writing-mode use case HOT 3
- Broken link in http://usecases.responsiveimages.org/ HOT 2
- add support for image size based media queries
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from ri-usecases.