.
Thoughts?
Thanks,
Daniel Holbert
Mozilla Corporation
P.S. Thanks to Robert O'Callahan for coming up with this proposal a week
or so back.
P.P.S. Browser versions that I tested (on Ubuntu 11.04 x86):
Firefox 6.02
Opera 11.51
Chromium 14.0.835.126 (Developer Build 99097 Linux)
[1] https
On 09/10/2011 04:53 PM, Nils Dagsson Moskopp wrote:
Browsers handle the # character in data URIs very differently, and
the arguably correct behavior is probably not what authors actually
want in many cases.
Do you have any evidence for that assertion, e.g. author surveys,
occurance in sites,
On 09/10/2011 08:09 PM, Bjoern Hoehrmann wrote:
So he would
make the same suggestion even if everybody implemented the correct beha-
vior.
No -- sorry if I wasn't clear on that. A big part of the motivation for
this proposal right now is the inconsistent level of forgiveness
across
On 09/11/2011 07:21 AM, Michael A. Puls II wrote:
Not only must # be %23 if you don't want it as a frag id, but
and should be %3E and %3C.
[...]
Of course, if you can percent-encode everything needed as you type, you
can hand-author the URI data. But, who wants to do that,
As I noted in a
On 09/14/2011 01:26 AM, Julian Reschke wrote:
On 2011-09-14 10:16, Robert O'Callahan wrote:
Yeah. Will you fix it in Webkit? :-)
:-)
Maybe we should start with opening a ticket, so this is properly tracked?
I'll file a few WebKit bugs and report back with bug links for those who
are
Hi folks,
Boris Zbarsky and I ran across a not reflecting reality issue in the
WHATWG HTML spec.
The spec currently defines the rendering of the br element as follows:
# br { content: '\A'; white-space: pre; }
Source:
text there may likely be impacted by how br itself
is specced.
~Daniel
On 01/22/2014 01:51 PM, Daniel Holbert wrote:
Hi folks,
Boris Zbarsky and I ran across a not reflecting reality issue in the
WHATWG HTML spec.
The spec currently defines the rendering of the br element as follows:
# br
On 01/23/2014 03:16 AM, Stewart Brodie wrote:
[2] I only noticed one rendering difference -- IE11 honors border on
br, unlike the other browsers that I tested. (It still doesn't honor
e.g. display/width/height, though.)
I get different results on your test case for the bottom two tests. In
.
That seems relevant, but it still leaves things vague for me.
Thanks!
Daniel Holbert
Mozilla
P.S. For reference, object-fit/object-position are specced here:
http://dev.w3.org/csswg/css-images-3/#propdef-object-position
On 11/07/2014 09:35 AM, L. David Baron wrote:
On Thursday 2014-11-06 12:36 -0800, Daniel Holbert wrote:
Should these coordinates be relative to... (A) ...the top-left
corner of the img element itself? OR (B) ...the top-left corner
of the rectangle where the image's pixel data actually maps
On 11/07/2014 09:42 AM, Anne van Kesteren wrote:
On Fri, Nov 7, 2014 at 6:35 PM, L. David Baron dba...@dbaron.org wrote:
I also think it should be (B), since the meaning of the coordinates
in the imagemap shouldn't change as a result of CSS styling of the
image.
Note that as Daniel pointed
On 06/24/2015 08:33 PM, Kevin Marks wrote:
Does this mean we can now have rel=icon with SVG instead of providing a
bitmap for every iOS device specifically (when we add to homepage)? Do
chrome and Firefox support SVG icon images?
Here's a simple testcase:
Hi whatwg,
Today I discovered that Apple is introducing a new pinned tab icon
feature, which unfortunately co-opts the existing HTML favicon syntax,
and is causing compatibility issues in Firefox Nightly.
BACKGROUND:
Quoting Apple's documentation[1] on this feature:
# Icons for Pinned Tabs
13 matches
Mail list logo
