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:
http://people.mozilla.org/~dholber
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
On 11/07/2014 09:42 AM, Anne van Kesteren wrote:
> On Fri, Nov 7, 2014 at 6:35 PM, L. David Baron 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 out it fo
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 element itself? OR (B) ...the top-left corner
>> of the rectangle where the image'
#x27;width'
# and 'height' properties.
#
# Note: [...] transforms applied using CSS or SVG
# do not affect the coordinates.
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 01/23/2014 03:16 AM, Stewart Brodie wrote:
>> [2] I only noticed one rendering difference -- IE11 honors "border" on
>> , 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 tw
text there may likely be impacted by how 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 renderin
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 element as follows:
# br { content: '\A'; white-space: pre; }
Source:
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#phr
On 09/14/2011 10:11 AM, Daniel Holbert wrote:
I'll file a few WebKit bugs and report back with bug links for those who
are interested.
Filed: https://bugs.webkit.org/show_bug.cgi?id=68089
(Component is "New Bugs" right now, because I wasn't sure where
data-URI-pa
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 intere
On 09/12/2011 12:47 PM, Michal Zalewski wrote:
What about javascript: URLs?
Right now, every browser seems to treat javascript:alert('#') in an
"intuitive" manner.
FWIW -- in Gecko, I believe we actually do split "#')" out as a fragment
identifier there (under-the-hood in our URI parsing code
On 09/11/2011 02:09 AM, Julian Reschke wrote:
Given the fact that this change made it into the release without any
major uproar there might be a chance that other UAs might simply adopt it.
(To be clear -- the proposal hasn't made it into any releases yet. Right
now it's just an idea.)
~Dani
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,
A
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 brows
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,
> occuranc
ot of the time; Opera sometimes behaves like Webkit and
sometimes not; and Firefox parses fragment-identifiers strictly,
potentially giving authors headaches and truncating content that renders
fine in Opera/Webkit.
With my proposal here -- relaxing the situations under which "#" should b
16 matches
Mail list logo
