ly, and then if needed convert to device
RGB as the very last step (in GPU/by the OS)? It would make all current web
content render consistently as expected. Support for the niche use case of true
display of full gamut of wider-than-sRGB profiles can be added less urgently.
--
Kind regards, Kornel
le seems OK to me. It'd mean the
website already knows how to convert colors to the given colorspace, and the
same profile could be passed back by toDataURL().
--
Kind regards, Kornel
/v1/images/raw/fticon:brand-ft?format=svg&tint=fff1e0,fff1e0&source=example
For this case Safari requires theme-color to be changed to black, but that
would make the entire UI of Chrome for Android black, which is also
unacceptable.
--
Kind regards, Kornel Lesiński
meet the requirement of enforcing a monochrome image
(authors that mixed colors against the advice would get one color that is a
blend).
And all this would be achieved without the need for another metatag, and the
mask icon would the same in other browsers.
--
Kind regards, Kornel Lesiński
agent can colorize:
This way authors can control whether they want the icon to be reused as a
regular icon, with , or not, by using this
relationship alone.
--
Kind regards, Kornel Lesiński
ests (win/win).
For server push we already have Server-Sent Events:
https://html.spec.whatwg.org/multipage/comms.html#server-sent-events
> I’m not really concerned with how this is solved, but an example would be to
> add to XMLHTTPRequest:
XHR is dead.
https://fetch.spec.whatwg.org/
--
regards, Kornel
es makes extensibility uglier. You won't be able to
elegantly add methods that are valid only for some types of locks, e.g. `new
WakeLock("cpu").dimScreen()` is nonsense, but would valid from perspective of
WebIDL and JS prototypes.
--
regards, Kornel
> On Monday, August 18, 2014 at 6:24 PM, Kornel Lesiński wrote:
>
>> I think it'd be unfortunate if this API had just one shared lock per
>> browsing context and required components on the page to coordinate locking,
>> but provided no means to do so.
>
>
ess explicitly
dependent on CSS).
With CPU lock it's less clear cut. I think tying it to a notification may be a
good idea. Alternatively, perhaps the lock itself could be an instance of the
element that author is supposed to insert to the document? ;)
--
regards, Kornel
p API
var cpuLock = new navigator.CpuLock();
cpuLock.setThreadPriority("low"); // completely made-up API
--
regards, Kornel
x27;t unlock any other component's lock
This makes coordination easier: each page component can easily create their own
lock independently (without needing to create an iframe to get their own lock),
and can't release any other component's lock.
--
regards, Kornel
e between source and predicted values for pixels acts similarly to
JPEG's quality level.
So there are multiple ways such parameter can be interpreted, and it can result
in wildly different visual quality, file size and time taken to compress the
image.
--
regards, Kornel
[1] https://github.com/pornel/zopfli
unambiguously matched to be loaded or empty source set will cause
selection algorithm to do nothing.
--
regards, Kornel
y.from(this).map(...whatever);
}
NodeList.prototype.forEach = function(...whatever) {
return Array.from(this).forEach(...whatever);
}
etc.
--
regards, Kornel Lesiński
grids with a month view
could style specific pseudo-elements for this layout and mobile browsers
could ignore these styles completely.
--
regards, Kornel
ake that easy enough).
--
regards, Kornel
tly on img that
conflict with picture's definitions.
--
regards, Kornel
On 25 November 2013 10:59:15 Yoav Weiss wrote:
On Mon, Nov 25, 2013 at 11:32 AM, Kornel Lesiński wrote:
> If picture was explicitly controlled by img then websites could start
> depending on that behavior, and we'd be stuck with it. OTOH picture can
> have "native"
g
that preload scanner uses internally.
I think we don't need to add any runtime behavior changes for this, as
scripts constructing will not insert explicit fallback node
- it makes more sense to rely on polyfill instead (that will use
img with correct src from the start).
--
regards, Kornel
ing (in case they need to emulate
for existing screen readers or accessibility APIs).
I've dropped usemap. It could be added, but I'm not sure if there is need
for it.
I've specified very few IDL attributes. This area may need to be extended.
--
regards, Kornel
an we hide the "controlling" in shadow DOM? And make
HTMLPictureElement the interface that proxies relevant properties/events
to the internal ?
Reuse of is a great idea for simpler implementation and testing, but
maybe we don't even need to expose that fact to the authors.
--
regards, Kornel
ific problems and complexity of MediaElement algorithms and
APIs, and is not inherent to use of elements in HTML in general.
Images don't need to expose API for buffering, seeking, playback states,
etc. Image sources can be evaluated using simple, stateless atomic
algorithm - basically same algorithm as you'd use for an attribute, but
instead of using custom attribute parser you read attributes from child
nodes.
--
regards, Kornel
s is something that can be shared between browser vendors, and
the community can help adapt test cases to , so we can
spread the effort.
--
regards, Kornel
On Wed, 20 Nov 2013 05:24:21 -, Bruno Racineux
wrote:
If your sources and breakpoints are hard-coded in your articles (stored
DB), and you suddenly have to change your site's theme, or add a new
image at the platform level or a new resolution? What if one breakpoint
is no
longer rele
ok a lot like discussions in RICG
years ago, so hopefully we'll eventually come to the same conclusions as
RICG did ;)
--
regards, Kornel
later/as needed (e.g.
, , ,
etc.) without risking explosive complexity of combined microsyntaxes.
--
regards, Kornel
eptable[2].
I'd love to hear feedback about simplified, atomic from other
vendors.
[1]
https://github.com/ResponsiveImagesCG/picture-element/issues/62#issuecomment-24479164
[2] http://lists.w3.org/Archives/Public/public-html/2013Sep/0185.html
--
regards, Kornel
preloader or offer users/UAs ability to control
image selection.
Basically authors will hate us. We've been going in circles for a couple
of years now and all we have to offer is an incomplete solution? And
browser vendors can't even agree which one of the half-baked solutions is
it going to be :(
--
regards, Kornel
they prefer syntax over
src-N.
--
regards, Kornel
aturalWidth
== 0).
--
regards, Kornel
don't like being zoomed in would just block it
via .
--
regards, Kornel
n document fragments should be
minimal.
Maybe it's not "cool", but keeping it away from document fragments buys
nothing, and just makes the platform less consistent.
--
regards, Kornel
.
In that case it'd be better to return ArrayBuffer, so the user can wrap it
in any type they want (including DataView).
--
regards, Kornel
mated slow movement choppy, so authors may also want
ability to disable it for selected paths/drawing operations or even for
each axis separately (e.g. to smoothly animate horizontal movement while
object is snapped to pixels vertically, etc.)
--
regards, Kornel
ogical.
For 1-pixel lines it could be fixed by allowing authors to specify that
path should be stroked with lines aligned to inside/outside of the path
(which is a useful feature on its own).
--
regards, Kornel
ES6 modules[1] have a script loader API[2].
That API is pretty powerful to the point it can emulate other script
loaders, load files that are not ES6 modules, and even load text files
that aren't JS (intended for compilation of coffeescript-like languages,
but could be abused for anything)
rotation:false})
--
regards, Kornel
On Tue, 09 Jul 2013 20:39:45 +0100, Ian Hickson wrote:
Would something like this, based on proposals from a variety of people in
the past, work for your needs?
1. Add a "dependencies" attribute to that can point to other
scripts to indicate that execution of this script should be delayed
On Fri, 12 Jul 2013 21:20:57 +0100, Kyle Simpson wrote:
So, just to clarify, `
On Wed, 10 Jul 2013 16:39:42 +0100, Kyle Simpson wrote:
I personally don't care about scripts being discoverable by pre-parsers.
[...]
For instance, I've added like annotations for my
scripts into the head of my document, and then done my normal
script-based script loading as usual, and b
quot;1x" screen, not even "2x"
yet.
--
regards, Kornel
lternative would be equivalent to alt="alternative"> (alternative present).
--
regards, Kornel
easy workaround for that may be to treat fallback/alt
similarly to content, i.e. just forbid focusable/interactive
elements. Do any UAs allow users to access in rendered ?
--
regards, Kornel
ould
be shown, and then the link would be accessible.
--
regards, Kornel
g. draw of ) is executed,
3. snapshot,
4. empty the buffer
5. goto 2
That could make readbacks much less frequent. Would this still be a
prohibitively expensive solution?
--
regards, Kornel
euristics
and accepted risk of loss, e.g. don't snapshot for 1/10th of a second
after canvas has been cleared, don't log commands from
requestAnimationFrame() etc.
--
regards, Kornel
ed in – are you?
Best scaling ratios are linear, rounded to nearest integer (i.e. 3x is OK too).
That's quite common in computer science, and not surprising when dealing with
discrete unit like device pixel.
--
regards, Kornel
eens (like most desktop monitors
settled on ~100dpi) or use "fake" 2x (scaled viewport) than expect authors to
make pixel-perfect designs for 1.25, 1.5, 1.75, 2.25, etc.
--
regards, Kornel
lays become the norm the minimal useful
HTML template will grow to be something like:
html {image-resolution:2dppx}
and I'm trying to find a way to avoid having all authors add yet another
boilerplate opt-in.
I don't know what to do with default-lowres background-image, so maybe
this is an unavoidable problem :(
--
regards, Kornel Lesiński
tion algorithm.
In that case I think the syntax with separated attributes is less clear
than a microsyntax in a single attribute — list in a single attribute has
obvious ordering and doesn't rely on an ordered set of predefined names.
--
regards, Kornel Lesiński
edia query could end up delimiting
sources in some implementations, and then we'll end up with worst of both
worlds (both ambiguous comma and other unintuitive delimiter needed for
web-compat).
--
regards, Kornel Lesiński
icrosyntax
>> * `width` and `height` — analogous to `` for each
>> alternative image
> * alt
> * title
> are missing IMO.
title is global, so available for too. Might be worthwhile to specify how
title on behaves.
As I've mentioned earlier I think it's not appropriate to have alt for
non-visual agents vary based on visual properties.
> What about
> * usemap
> * ismap
> ?
Aren't these "legacy" features?
--
regards, Kornel
ageB and imageD (both have the same query
that matched).
imageC will never be used (because imageA will always match earlier and it
has a different media query).
alt text
UA can choose resolution of portrait or landscapa version of the image.
Same as:
alt text
--
regards, Kornel Lesiński
On 22 maj 2012, at 15:57, "Tab Atkins Jr." wrote:
> On Tue, May 22, 2012 at 7:26 AM, Kornel Lesi��ski wrote:
>> I think that 3x device is very very unlikely to ever happen, since 2x
>> screens are may be dense enough to have pixels smaller than human eye can
>>
Sorry, I forgot to clarify this ― I had in mind adding width/height on each
element, not on .
--
regards, Kornel
On 22 maj 2012, at 16:01, Maciej Stachowiak wrote:
>
> On May 21, 2012, at 9:37 PM, Kornel Lesi��ski wrote:
>
>>
>>
>>> There’s no prio
quests when window is resized.
It doesn't work with static file servers, and may be costly/problematic for
CDNs.
Another risk is that authors will create files only for size/DPI of iPhone and
iPad and never supply images for 3000 other resolutions of various Android
devices.
--
regards, Kornel
ply adding `width` and `height` attributes on the element
(similar to `img`) might solve this, in the event that the author wants
to rely on an intrinsic size instead of CSS?
I think that is a very good idea. Having option to do so is good for
performance, as it avoids reflows.
--
regards, Kornel Lesiński
On 19 maj 2012, at 10:46, Matthew Wilcox wrote:
> 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 w
detail previously (using srcset as an example,
but it all applies to min-device-pixel-ratio: MQ as well)
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-May/036051.html
--
regards, Kornel Lesiński
I've tried to raise those issues on the Responsive Images group's
mailinglist, but got no constructive feedback.
--
regards, Kornel Lesiński
stateful and non-uniform nature of caches that should be taken into
account.
So please specifically address cases I've listed in my previous email.
--
regards, Kornel
On 18 maj 2012, at 10:52, Matthew Wilcox wrote:
> Thanks for all the feedback everyone.
>
> I don't th
On Thu, 17 May 2012 19:32:51 +0100, Jeremy Keith
wrote:
Kornel wrote:
Note that the scale multiplier can be omitted already when only the
size is specified
I'm confused by what you mean by scale multiplier. The x value describes
the pixel density of the device/screen, not the
fault?
Because it's simple (1 image pixel = 1 CSS pixel), and it was the
historical default.
But it's going to become completely useless and nobody is going to use it.
2x default at least has a chance of not being useless.
--
regards, Kornel Lesiński
y?
i.e. is the rule going to be "first which matches at any density" or
"first which matches at desired density, and failing that the first which
matches at any other density"?
--
regards, Kornel Lesiński
r will give less wrong result — a 2x image.
Only if we change the default to 3x now, before srcset ships we will avoid
the problem entirely. But as I've explained above, it's an inconvenient
scaling factor and is likely to overshoot required quality, so 2x is a
safer bet.
But why oh why should we keep 1x as the default if it's going to be the
worst default in any case?
--
regards, Kornel Lesiński
so I want to use short/wide version of the
design in landscape orientation.
And I have a square illustration in my content. It doesn't flip on
orientation, but I want it to be 500x500px on 1000px+ screens, and
320x320px on smaller ones.
In some srcset-source pseudocode I'd say:
How would you do that with breakpoints?
--
regards, Kornel Lesiński
screen and viewing distance 2x is already claimed to be perfect ("Retina"
display).
--
regards, Kornel Lesiński
ent? (mostly fixed-width sidebar with fluid main column)
or if your page header adapts to portrait orientation, but images in main
content only adapt to width?
--
regards, Kornel Lesiński
f escaping for commas in the URL part:
srcset="a,b" two URLs
srcset="a\,b" one URL "a,b"
srcset="a\\\, , \,b" two URLs "a\," and ",b"
--
regards, Kornel Lesiński
s DPI, e.g.
obama-f...@2x.jpg vs obama-with-audie...@2x.jpg
and possibly negotiate on both axes at the same time:
obama-f...@2x.jpg vs obama-with-audie...@2x.jpg vs
obama-f...@1x.jpg vs obama-with-audie...@1x.jpg
--
regards, Kornel Lesiński
oesn't
take any functionality away.
--
regards, Kornel Lesiński
images it has downloaded and re-download them in poor quality?
What when I reload or browse to a next subpage? My browser still has
high-res images in the cache. Should it now apply low-end design and
re-download all images in poor quality?
--
regards, Kornel
s for
media="(case: breakpoint1)" in .
--
regards, Kornel Lesiński
(satellite, 3G/4G) it may
already be cheaper to download all versions of all images than to wait for
CSS to be able to select the right ones to load. Solution that requires
page layout for image loading is a step backwards for performance.
--
regards, Kornel Lesiński
may be computationally
expensive, so it would further delay time it takes to start loading images.
And finally corner cases can lead to loops:
--
regards, Kornel Lesiński
een prepared for it, without need to
update code that embeds those images? And is that really saving much
effort? Wouldn't you have to revisit every page anyway to test the new
layout?
[1]http://www.w3.org/community/respimg/2012/05/13/an-alternative-proposition-to-and-srcset-with-wider-scope/
--
regards, Kornel Lesiński
oth well,
since there's a fundamental difference between author-controlled and
UA-controlled decision.
--
regards, Kornel Lesiński
ng)
It may be enough to add another attribute that describes image properties,
and can be used either alone or with conjunction with MQs:
would be equivalent to:
(I've proposed that in the RespImg community group)
And combination of the two opens new possibilities:
--
regards, Kornel Lesiński
SVG gradient syntax which
was usable before CSS gradients. HTML5 DOCTYPE is loved. Brevity matters.
--
regards, Kornel Lesiński
need to resort to tricks with downsizing
high-res images to smaller size.
For a full-width image on a ~960px viewport (assuming author doesn't have
better sizes available) this would be appropriate:
style="width:100%">
--
regards, Kornel Lesiński
ze information may be the solution:
then UA can easily make decision how much bandwidth it can use (e.g. aim
to download any page in 5 seconds, so try to get image sizes to add up to
less than 5*network B/s).
--
regards, Kornel Lesiński
o show dog-lo.jpg rather
than dog.jpg.
But still displayed at 960 CSS pixels or course? That'd be fine (and the
UA could even download dog@2x when user zooms in).
--
regards, Kornel Lesiński
wrong design that was chosen based on a temporary network state.
There is no such problem if only same-CSS-pixel-size images are swapped
in-place.
--
regards, Kornel Lesiński
ot;world-map-showing-most-popular-browser-in-each-country.png">
CountryMost popular browser...
Trying to put all data in alt="" wouldn't work well, and
doesn't contain the information that the map conveys, so that's at best a
caption, not an alternative.
--
regards, Kornel Lesiński
with them. Bandwidth/DPI requirements are known to UA
and there can be same set of UA-specific rules that works for all pages.
--
regards, Kornel Lesiński
rsion adapted to page
layout, and another mechanism connected to would allow UA to
choose image resolution.
--
regards, Kornel Lesiński
selecting right images, their
purposes and requirements are very different.
--
regards, Kornel Lesiński
tion about image. It wouldn't be possible/sensible
to do with a media query.
Even if there was support for something like media="user-action:save-as">, I can bet that less than 0.5% of pages would
use it and do it correctly.
--
regards, Kornel Lesiński
blem of MQ
being inappropriate for bandwidth and relies on authors choosing the right
criteria.
Perhaps there should be an attribute(s) on that describes
properties of the resource, and could be used for both video and images?
--
regards, Kornel Lesiński
ill be automatically
resized one way or another.
Therefore, I expect browsers/systems to continue using fake 96dpi/192dpi
snapped to device pixels, and artists to focus only on those ratios. It's
simplest for everybody and gives device-pixel-perfect rendering on varying
screen densities.
--
regards, Kornel Lesiński
16/summary-of-use-cases-and-requirements/
--
regards, Kornel Lesiński
ewport) is not widely supported yet.
However, the design and usability of is terrible. You'll
find a lot of pages on the web that get "," vs ";" wrong in the meta
content.
--
regards, Kornel Lesiński
lace it with
whatever it wants.
Another use case would be a (superficial) emulation of document.write()
for scripts that have been embedded asynchronously.
--
regards, Kornel Lesiński
sing models are
understood.
Dusting off proposal, which doesn't have that problem:
http://www.w3.org/html/wg/wiki/ChangeProposals/hSub
--
regards, Kornel Lesiński
better to combine two very simple media
queries for orientation with simple declaration of adaptive image
resolution (that makes browser automatically take into account screen
size/density and network speed, without needing details spelled out by the
page author).
--
regards, Kornel Lesiński
into
account various screen sizes, DPI and bandwidth/metering at the same time.
When browser has a high-quality image the cached already, but media query
for "network-connection: gprs" matches, it would be shame to force it to
switch to a lousy image.
--
regards, Kornel Lesiński
is
off and only connect when necessary and only request files that have
changed substantially.
--
regards, Kornel Lesiński
On Mon, 06 Feb 2012 20:00:45 -, Irakli Nadareishvili
wrote:
1. Adaptive images:
To optimize user-experience on smart-phones (most of which have
relatively small screens, and are on slow connections most of the time)
Be careful with generalizations like that.
Mobile devices can be con
ibility with
developers, not browsers).
--
regards, Kornel Lesiński
one") — just
to be consistent and use same name for the same thing.
Order of words in cc-full-name is inconsistent with name-full.
hCard uses "given-name" and "family-name", while current autocomplete
proposal has same "given-name", but uses "surname". It would be nice to
rename autocomplete types for consistency with hCard where possible
(unless they're consistent already with something else I don't know :)
--
regards, Kornel Lesiński
1 - 100 of 244 matches
Mail list logo