On 18/11/13 03:25, Daniel Cheng wrote:
On Mon, Nov 18, 2013 at 12:19 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Sun, Nov 17, 2013 at 5:16 AM, Ryosuke Niwa rn...@apple.com wrote:
Without starting a debate on what semantics or aesthetics mean, syntax
is a big deal. A bad syntax can
On Thu, Nov 14, 2013 at 10:45 PM, Andrew Wilson atwil...@google.com wrote:
var n1 = new Notification(title);
var n2 = new Notification(title, {icon: invalid_icon_url});
var n3 = new Notification(title, {icon: http://non-existent-icon.com});
I think that it should be:
n1.dir == auto
n1.lang
On Wed, Nov 13, 2013 at 1:36 PM, Robert O'Callahan rob...@ocallahan.orgwrote:
On Wed, Nov 13, 2013 at 12:12 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com wrote:
Path is also too generic even in the context of graphics. If we later on
want to add a path object for 3-dimensional paths,
On Sunday, November 17, 2013 at 8:07 PM, whatwg-requ...@lists.whatwg.org wrote:
Date: Sun, 17 Nov 2013 08:19:00 -0800
From: Tab Atkins Jr. jackalm...@gmail.com (mailto:jackalm...@gmail.com)
To: Ryosuke Niwa rn...@apple.com (mailto:rn...@apple.com)
Cc: whatwg wha...@whatwg.org
On Mon, Nov 18, 2013 at 1:01 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Nov 14, 2013 at 10:45 PM, Andrew Wilson atwil...@google.com
wrote:
var n1 = new Notification(title);
var n2 = new Notification(title, {icon: invalid_icon_url});
var n3 = new Notification(title, {icon:
On 18.11.2013 14:38, Marcos Caceres wrote:
we really need to, srcset. The developer community already made
significant sacrifices in compromising on picture because of issues
that implementers raised about nested elements
Are those issues with nested elements described somewhere? I wasn't
On Nov 18, at 10:34 AM, Jirka Kosek wrote:
On 18.11.2013 14:38, Marcos Caceres wrote:
we really need to, srcset. The developer community already made
significant sacrifices in compromising on picture because of issues
that implementers raised about nested elements
Are those issues with
On 18/11/13 16:36, matmarquis.com wrote:
I recall that some of the more
specific resistance was due to the complication involved in
implementing and testing existing media elements, but I can’t claim
to understand precisely what manner of browser-internal complications
`source` elements brought
On Sun, Nov 17, 2013 at 3:11 PM, Maciej Stachowiak m...@apple.com wrote:
It seems like the blockers to this syntax working as-is are:
- For Safari and Chrome, url(attr()) doesn't work.
This will never work; for legacy compat reasons, url() is not a
function, but a syntax construct specially
On Monday, November 18, 2013 at 3:34 PM, Jirka Kosek wrote:
On 18.11.2013 14:38, Marcos Caceres wrote:
we really need to, srcset. The developer community already made
significant sacrifices in compromising on picture because of issues
that implementers raised about nested elements
On Monday, November 18, 2013, Rik Cabanier wrote:
On Wed, Nov 13, 2013 at 1:36 PM, Robert O'Callahan
rob...@ocallahan.orgjavascript:_e({}, 'cvml', 'rob...@ocallahan.org');
wrote:
On Wed, Nov 13, 2013 at 12:12 PM, Jussi Kalliokoski
jussi.kallioko...@gmail.com javascript:_e({}, 'cvml',
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2643
In my testing, getSVGDocument is supported on embed, frame,
iframe and object in Firefox Nightly, IE11 Preview, Safari 7.0 and
Opera 12.16, the only exception being frame.getSVGDocument in Firefox.
I don't know if this API is
On 11/18/13 1:37 PM, Philip Jägenstedt wrote:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2643
In my testing, getSVGDocument is supported on embed, frame,
iframe and object in Firefox Nightly, IE11 Preview, Safari 7.0 and
Opera 12.16, the only exception being
On Mon, Nov 18, 2013 at 2:40 AM, James Graham ja...@hoppipolla.co.uk wrote:
This ugliness creates real issues e.g. if I have src-1, src-2 [...] and I
decide I want a rule that is consulted between src-1 and src-2, I need to
rewrite all my attribute names. Whilst this might produce a pleasant
On Mon, Nov 18, 2013 at 8:58 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Nov 18, 2013 at 2:40 AM, James Graham ja...@hoppipolla.co.uk
wrote:
This ugliness creates real issues e.g. if I have src-1, src-2 [...] and I
decide I want a rule that is consulted between src-1 and src-2, I need
On Mon, Nov 18, 2013 at 9:40 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Nov 18, 2013 at 12:32 PM, Yoav Weiss y...@yoav.ws wrote:
On Mon, Nov 18, 2013 at 8:58 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Nov 18, 2013 at 2:40 AM, James Graham ja...@hoppipolla.co.uk
wrote:
On Mon, Nov 18, 2013 at 12:32 PM, Yoav Weiss y...@yoav.ws wrote:
On Mon, Nov 18, 2013 at 8:58 PM, Jonas Sicking jo...@sicking.cc wrote:
On Mon, Nov 18, 2013 at 2:40 AM, James Graham ja...@hoppipolla.co.uk
wrote:
This ugliness creates real issues e.g. if I have src-1, src-2 [...] and I
On Mon, Nov 18, 2013 at 8:02 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/18/13 1:37 PM, Philip Jägenstedt wrote:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2643
In my testing, getSVGDocument is supported on embed, frame,
iframe and object in Firefox Nightly, IE11
On Nov 18, 2013, at 9:05 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Sun, Nov 17, 2013 at 3:11 PM, Maciej Stachowiak m...@apple.com wrote:
It seems like the blockers to this syntax working as-is are:
- For Safari and Chrome, url(attr()) doesn't work.
This will never work; for legacy
Some comments on srcset and src-N, and a radically different proposal.
ART-DIRECTION
First, I don't think the Art-direction issue should be solved at img
level, because it's only a partial solution and replicates a feature
already provided by CSS. For example, providing a less detailed image
On Mon, Nov 18, 2013 at 1:35 PM, Maciej Stachowiak m...@apple.com wrote:
I'm not enough of a CSS expert to understand the implications of that change.
What would be the observable behavior changes that 'content: replaced' would
produce?
- For Firefox, the 'content' property doesn't work on
On 11/18/13 5:38 AM, Marcos Caceres w...@marcosc.com wrote:
Agree. It would be ideal to try to find a way forward here with src-n.
Mozilla is not really interested in restarting this whole effort again
with imgset or new CSS-in-the-head proposals (though, of course,
orthogonal improvements to
On Mon, 18 Nov 2013 16:47:08 -, James Graham ja...@hoppipolla.co.uk
wrote:
On 18/11/13 16:36, matmarquis.com wrote:
I recall that some of the more
specific resistance was due to the complication involved in
implementing and testing existing media elements, but I can’t claim
to understand
On Nov 18, 2013, at 2:54 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Mon, Nov 18, 2013 at 1:35 PM, Maciej Stachowiak m...@apple.com wrote:
I'm not enough of a CSS expert to understand the implications of that
change. What would be the observable behavior changes that 'content:
On Mon, Nov 18, 2013 at 5:01 PM, Kornel Lesiński kor...@geekhood.net wrote:
On Mon, 18 Nov 2013 16:47:08 -, James Graham ja...@hoppipolla.co.uk
wrote:
On 18/11/13 16:36, matmarquis.com wrote:
I recall that some of the more
specific resistance was due to the complication involved in
On Mon, Nov 18, 2013 at 5:08 PM, Maciej Stachowiak m...@apple.com wrote:
I see. It seems like it would be simpler to just define content on a real
element to have the existing WK/Blink behavior without saying replaced. It
is not obvious why ignoring the element size is a useful default
On 18 November 2013 23.18.37, Bruno Racineux wrote:
For all it's worth, my outside take on both of srcset and src-N has always
been that it's not DRY enough, and more unnecessary bloat to pages, due
the long unnecessary repetition of img-path(s) for each img of similar
size, repeating the same
On 11/4/13 6:25 AM, Anne van Kesteren wrote:
We should add it to DocumentFragment I think. That will be useful for
ShadowRoot too.
OK, agreed. Landed this for DocumentFragment in Gecko.
-Boris
On Tue, 19 Nov 2013 01:12:12 -, Tab Atkins Jr. jackalm...@gmail.com
wrote:
AFAIK it makes it as easy to implement and as safe to use as src-N.
Simon, who initially raised concerns about use of source in picture
found that solution acceptable[2].
I'd love to hear feedback about simplified,
On Nov 18, 2013, at 5:55 PM, Kornel Lesiński kor...@geekhood.net wrote:
On Tue, 19 Nov 2013 01:12:12 -, Tab Atkins Jr. jackalm...@gmail.com
wrote:
AFAIK it makes it as easy to implement and as safe to use as src-N.
Simon, who initially raised concerns about use of source in picture
On Mon, 18 Nov 2013 23:18:37 -, Bruno Racineux br...@hexanet.net
wrote:
All I hear from implementors as a whole, is that: you don't want to go
the css imgset or image-set road, you won't use src-templates, and you
don't
want any new macro. Seriously, what it left?
Indeed, the
On 11/18/13 4:25 PM, Qebui Nehebkau qebui.neheb...@gmail.com wrote:
Many people seem to find regexps
difficult to understand, and the regexps involved would only get more
difficult as the complexity of URL patterns increases. Forcing authors
to use them sounds like a great way to guarantee
On 11/18/13 6:21 PM, Kornel Lesiński kor...@geekhood.net wrote:
However, the most terse syntaxes are starting to look like Perl. It's not
always the best idea to squeeze every byte out of a syntax.
Even if none of existing proposals is perfect in terms of DRY, I think
overall they're good
On Mon, Nov 18, 2013 at 8:13 PM, Bruno Racineux br...@hexanet.net wrote:
Because these (only 0.2% uzing gzip) stats do not look good at all in
support of your theoretical argument:
http://trends.builtwith.com/Server/GZIP-Module
That measures mod_gzip adoption.
HTTP Archive tracks top 300K
On 11/18/13 8:21 PM, Ilya Grigorik igrigo...@gmail.com wrote:
On Mon, Nov 18, 2013 at 8:13 PM, Bruno Racineux br...@hexanet.net wrote:
Because these (only 0.2% uzing gzip) stats do not look good at all in
support of your theoretical argument:
http://trends.builtwith.com/Server/GZIP-Module
On Tue, Nov 19, 2013 at 5:53 AM, Bruno Racineux br...@hexanet.net wrote:
On 11/18/13 8:21 PM, Ilya Grigorik igrigo...@gmail.com wrote:
On Mon, Nov 18, 2013 at 8:13 PM, Bruno Racineux br...@hexanet.net
wrote:
Because these (only 0.2% uzing gzip) stats do not look good at all in
36 matches
Mail list logo
