Re: [whatwg] A mask= advisory flag for link rel=icon
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/~dholbert/tests/favicon/test1.html Firefox 41 (currently on Nightly, hitting release in late September) supports SVG favicons. (Earlier versions have partial support due to a bug with our favicon cache - the SVG favicon would work on first load, but would fail to show up on subsequent loads. That was fixed here: https://bugzilla.mozilla.org/show_bug.cgi?id=366324 ) From my brief testing with my testcase above (Chrome 45 dev channel on linux, Edge on Win10, Safari 8 on Yosemite), it doesn't look like other browser support SVG favicons right now, though. ~Daniel
[whatwg] Apple's new link rel=icon mask not-quite-favicon syntax causing problems in other browsers; needs standardization?
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 # You can set the icon that the user sees when # they pin your site by providing a vector image. # -- # Use 100% black for all vectors [...] # # link rel=icon sizes=any mask href=website_icon.svg # # To specify the color the icon should be displayed # in, add the theme-color meta element to your webpage: # # meta name=theme-color content=red Unsurprisingly, other browsers (Firefox Nightly at least[2]) interpret these link tags as an *actual* favicon, since it's valid syntax for a favicon. Meanwhile, we don't recognize meta name=theme-color, so we end up just rendering the SVG favicon -- which is entirely black. We're currently running into this with Twitter[3], Yelp[4], and Pinterest[5], which are all early-adopters of this Apple feature. Apple suggests that these new elements 'should be placed before other link rel=icon elements to avoid compatibility issues' -- if sites follow this guideline, it should make other browsers ignore the markup and honor the final real favicon. But unfortunately, these 3 sites (Twitter, Yelp, and Pinterest) did not follow this guideline. We can reach out to these sites, but given that these early-adopters are already incorrectly using this feature and breaking their favicons in Firefox (at least), I worry that many more sites will as well, as this feature gets more adoption. QUESTIONS: (1) Has there been any effort to standardize Apple's syntax for the pinned-tab-icon feature? (2) Is there any interest in standardizing the syntax at this point? (e.g. perhaps defining that the mask attribute on a link rel=icon element means it's *not* a favicon? [if this is what Safari does for non-pinned tabs]) There was a suggestion on one of the bugs that we simply ignore link tags that have a mask attribute; this may be what we want to do to avoid having a zillion site-compat conversations, but I wanted to get other vendors/spec-authors' opinions before considering this option too seriously. Thanks, ~Daniel [1] https://developer.apple.com/library/safari/releasenotes/General/WhatsNewInSafari/Articles/Safari_9.html#//apple_ref/doc/uid/TP40014305-CH9-SW20 [2] Note that SVG favicons didn't work reliably in Firefox until recent Nightlies; this was fixed in https://bugzilla.mozilla.org/show_bug.cgi?id=366324 [3] Yelp bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1174548 [4] Twitter bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1174552 [5] Pinterest bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1174568
Re: [whatwg] How do CSS object-position object-fit affect the coordinates used by image map/area?
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 to? (which may be inside or outside the bounds of the img element) (Of course, parts outside the img won't render and shouldn't receive clicks, but the rect is still there.) 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. I'm not sure I'd quite go that far (RE the meaning of coordinates in the imagemap shouldn't change as a result of CSS styling). I agree in an ideal world, but I don't think we can realistically honor that requirement -- and after thinking about it a bit more, I think I've shifted my opinion to favor (A). :) Stepping back a bit -- I guess there are really two separate questions here: (1) What should be the origin of the image-map pixels? (the upper-left of the img, or the upper-left of the displayed image data?) (2) How big should an image-map pixel be? (Should it be 1px in the img coordinate space (i.e. as wide as 1px of img-width), or should it be in terms of the image's intrinsic-sizing coordinate-space?) (I originally was just asking the first question, but it's probably more sensible to consider both questions together, to fully define the coordinate space.) Focusing on question (2) for the moment: it seems to me that the spec already forces the answer on this question to be use the img's CSS pixel sizing, given the historical note about width height. For example: given an 8px-by-8px square image, which is scaled up to 200px-by-100px using width and height properties, the spec *already* requires that the imagemap coordinates for the center of the image must be (100px,50px) -- not (4px,4px). So, this means the image-map pixels have to be sized according to the img element's CSS-pixel coordinate-space. I can't see a way to use any other pixel-sizing behavior while still preserving this result. So, given that the answer to question (2) is forced to be use the img's CSS pixel sizing, I think my feelings on question (1) are shifting to match that -- it seems like we should be consistent use the img's coordinate-space for that, too. (So, I'm now favoring option (A) from my original email here.) This has the benefit of making image-map coordinates reasonably easy to predict reason about, in display-space, at least. If we could redesign imagemap from scratch, I think it'd be ideal to let specific coordinates reliably map to specific places on the image, regardless of what CSS is applied to the image. But that's already broken by the width/height historical requirement, as noted above; and given that, I think the simplest thing is to just use the img's content-box coordinate-space.
Re: [whatwg] How do CSS object-position object-fit affect the coordinates used by image map/area?
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 out it for legacy reasons already does. img height/width and CSS height/width are the same. Not perpetuating that further makes sense though. I'm actually not so sure I agree (about not perpetuating that further). The width height legacy requirement basically ends up meaning that imagemap coordinates use the img's content-box as their coordinate space. In a More Perfect World, it'd arguably be more useful for specific imagemap coordinates to reliably to map to specific places in the image data (regardless of height/width), but it seems we've already lost that possibility. So, for now, we just have one useful assumption that we can make about these coordinates: they use the img's content-box as their coordinate space. I don't think we should let object-fit/object-position break that assumption, or else we risk making these coordinates completely incomprehensible / unusable. So, I'm now favoring option (A) from my original email. (See my reply to David for more thoughts on this.) ~Daniel
[whatwg] How do CSS object-position object-fit affect the coordinates used by image map/area?
Hi whatwg, I'm working on implementing the object-fit object-position CSS properties in Gecko (which allow authors to adjust the scaling/positioning behavior of image data inside of an img element), and I'm wondering how these properties should affect the coordinate space that's used by the map area elements. Spec reference for map and area: https://html.spec.whatwg.org/multipage/embedded-content.html#processing-model-2 QUESTION: The processing model's step 8 says to interpret coordinates as CSS pixels from the left [or top] edge of the image. i.e. coordinates are relative to the top-left corner of the image. But, what does that mean, for an image that's being rendered under the influence of object-fit / object-position? 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 to? (which may be inside or outside the bounds of the img element) (Of course, parts outside the img won't render and shouldn't receive clicks, but the rect is still there.) I tend to think B is the correct answer, but I'm not 100% sure, and I'd like a sanity-check. (Chrome is the only implementation that I've tested on this, and it appears to choose (A), which seems wrong to me. I'm not sure this was a conscious choice on the part of the developers, though, since this admittedly an obscure use-case, and easy to miss.) Also, FWIW: at the bottom of that same section, the spec says: # For historical reasons, the coordinates must # be interpreted relative to the displayed image # after any stretching caused by the CSS '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
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
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 Chrome 33 and Opera 12.16 (Linux), there is a line break; in Firefox 26 there isn't. Yeah -- sorry, I thought up those last two testcases (applying float and position:absolute to br) a bit later, after I sent my initial email. (which is why I didn't mention them as a rendering difference) So, the position float properties do represent a little bit of style that Gecko honors on br (but not Blink/Presto; not sure about IE). ~Daniel
[whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
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:
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#phrasing-content-1
This CSS implies that br's rendering could be customized by CSS, which
in practice (in the browsers that I tested[1]) is not actually the case.
In particular: given the spec's CSS quoted above, you might expect that
perhaps an author could set...
white-space: nowrap
... on a br element, to neuter the linebreak. That doesn't work,
though -- the br still triggers a linebreak. Similarly, you might also
expect to be able to customize the 'display' or 'height'/'width' or
'background' properties, but in practice, none of those have any effect
on br in modern browsers.
So: to reflect reality, it might be better to specify br in a way that
doesn't suggest it's as customizable with CSS. (for the white-space
property in particular, but probably others as well)
For reference, here's a page with a few testcases:
http://people.mozilla.org/~dholbert/tests/br-tests.html
The browsers that I tested[1] all agree on the rendering (basically, not
honoring any of the br styling), with one minor exception[2].
Thanks,
~Daniel
[1] I tested the following browsers:
Firefox 26
Opera 12.16
Chrome 34.0.1788.0 dev
IE 11
[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.)
Re: [whatwg] HTML spec incorrectly suggests that br can have its rendering changed with CSS
Note: part of the motivation for this concern is that the CSS Flexbox
spec likely needs a bit of tweaking to indicate how br elements in
runs of raw text should be handled, as I noted in this post to www-style:
http://lists.w3.org/Archives/Public/www-style/2014Jan/0317.html
...and the new spec 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 { content: '\A'; white-space: pre; }
Source:
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#phrasing-content-1
This CSS implies that br's rendering could be customized by CSS, which
in practice (in the browsers that I tested[1]) is not actually the case.
In particular: given the spec's CSS quoted above, you might expect that
perhaps an author could set...
white-space: nowrap
... on a br element, to neuter the linebreak. That doesn't work,
though -- the br still triggers a linebreak. Similarly, you might also
expect to be able to customize the 'display' or 'height'/'width' or
'background' properties, but in practice, none of those have any effect
on br in modern browsers.
So: to reflect reality, it might be better to specify br in a way that
doesn't suggest it's as customizable with CSS. (for the white-space
property in particular, but probably others as well)
For reference, here's a page with a few testcases:
http://people.mozilla.org/~dholbert/tests/br-tests.html
The browsers that I tested[1] all agree on the rendering (basically, not
honoring any of the br styling), with one minor exception[2].
Thanks,
~Daniel
[1] I tested the following browsers:
Firefox 26
Opera 12.16
Chrome 34.0.1788.0 dev
IE 11
[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.)
Re: [whatwg] Proposal for improved handling of '#' inside of data URIs
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 interested.
Re: [whatwg] Proposal for improved handling of '#' inside of data URIs
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 response to Nils earlier in this thread, Firefox/Webkit/Opera don't actually require authors to percent-encode brackets and spaces in data URIs. (not sure whether that's correct per spec or not). For example data:text/html,ihere is some italic texti works just fine in all three. So that makes it quite easy to hand-author data URIs, in fact. (aside from this # gotcha)
[whatwg] Proposal for improved handling of '#' inside of data URIs
Hi whatwg, I'm writing with a proposal to improve the handling of # in data URIs. I'm particularly looking for feedback from other browser vendors, but of course feedback from others is welcome as well. SUMMARY: Browsers handle the # character in data URIs very differently, and the arguably correct behavior is probably not what authors actually want in many cases. This could be more intuitive/do-what-I-mean if we restricted the cases under which # is treated as a fragment-ID delimiter inside of data URIs. In particular: when a # character is followed by or in a data URI, I propose that we *don't* treat the # as a delimiter, and instead just treat it as part of the encoded document. Now, a set of tests, to which I'll refer below: http://people.mozilla.org/~dholbert/dataURIHashTests/tests_v1.xhtml PROBLEM: When an author writes a data URI for a document that contains a # character, she may unintentionally end up with broken results (or at least inconsistently-handled results), because the # may be treated as the end of the document the beginning of the URI's fragment identifier. (I believe this to be the _technically_ correct (albeit unintuitive) behavior per the URI RFC [1] -- it's the behavior we've implemented in Firefox 6 [2] and it's what I've described as Correct in my testcase. (with quotes to indicate unintuitiveness)) Technically, the author *really* should encode the # character as %23, if she doesn't want it to be a delimiter. However, this gotcha is easy to overlook -- especially because Opera Webkit are less strict than Firefox in this respect and will gladly accept # inside data URIs under some circumstances. THE PROPOSAL HOW IT HELPS: We can help out the author by relaxing our fragment-ID-parsing rules a bit here. Note that in cases where an author *accidentally* includes # inside their data URI (e.g. body background=#f00), there almost certainly will be more content following it -- in particular, there will be an /html, or an /svg, or at least a (if it's inside the final tag) still to come. So we can proactively check for / characters anywhere after the #, and if we find them, then we can pretty safely assume that the author intended for the # to be part of the document, rather than a fragment-ID delimiter. OVERVIEW OF BROWSERS' CURRENT HANDLING OF # IN DATA URIs: === url: http://people.mozilla.org/~dholbert/dataURIHashTests/tests_v1.xhtml * Firefox 6+ breaks the author's expectations in my tests A B due to URI parsing strictness. (But if we were to implement the above proposal, we'd match the author's expectations.) We pass test C due to correctly trimming #target off of the end and scrolling to the referenced element. And we fail test D only due to a bug with over-enforcing same-origin checks.[3] * WebKit matches the author's expectations on A B -- however, that's only because they don't seem to support #ref suffixes on the ends of data URIs at all, so they _always_ include # in the document. (They *do* apparently support _relative_ references within data URI documents, e.g. xlink:href='#greenRect' as used in test B.) So, Webkit ends up failing test C because they don't strip off the #target suffix (resulting in broken XML). They fail test D presumably for the same reason. (They also have some zooming issues on the img examples, but I'm ignoring those for the purposes of this post.) * Opera is interesting -- it can exhibit either the Firefox or WebKit behaviors in tests A/B/C, depending on whether the data URI as an embedded element (via iframe/img) or view it directly. When you view it as an embedded element (in my testcase), Opera matches WebKit on A/B/C (including the XML parse error on C). However, if you *directly view* the data URIs (right-click on iframe, Frame|Open, focus URLbar hit enter), then Opera matches Firefox. Also, Opera passes test D. (I don't have results for IE -- I briefly tried to support it in the test, but I had issues getting data URIs to work there at all.) CONCLUSION: === So - to sum up the test-results above: webkit doesn't give # any special delimiter status in data URIs, which is a bug, but probably matches what authors intend a lot 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 be treated as a delimiter in a data URI -- I think we'd better match author expectations and improve the browser-compatibility picture. 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
Re: [whatwg] Proposal for improved handling of '#' inside of data URIs
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, number of duplicates in mozilla bugzilla (relative to other common bugs)? No large-scale data like that, just a few anecdotal reports in IRC of Firefox purportedly being broken on particular content (that contained a #), whereas Chromium was working. (one instance about a week ago, which prompted this proposal) Plus, a concern that people can *almost* just stick pure HTML/SVG into a data URI (see examples below) except for # characters which break things. This change would probably have to be communicated to other software working with data URIs (Python's urlparse module comes to mind). Sure, ultimately. One step at a time. Do you intend to update the RFC on the point or leave that usage non-conforming? I'm not sure. Right now this is just a proposal for better interoperability, but ultimately, yeah, it'd be great to have this specified. Note that in cases where an author *accidentally* includes # inside their data URI (e.g.body background=#f00), What's with the unencoded bracket (should be %3C) and space (should be %20) beforehand? Why wouldn't parsing stop at those points? Those are fine, actually -- but I should have included an actual URI that loads in browsers, like the following (this is what I meant): data:text/html,htmlbody style='background: #f00' So to answer your question -- that does render just fine (giant red page) in Chromium, without any need to encode the space or the brackets. It also renders fine in Opera if you point an iframe at it. (but not if you type it directly into the URLbar -- that's the inconsistency on their part that I mentioned in my post) And in Firefox, it renders fine if you just encode the # character: data:text/html,htmlbody style=background:%23f00 (that makes it load fine from Opera's URLbar, too.) So no -- practically at least, there's no need to encode the / or the space character. ~Daniel
Re: [whatwg] Proposal for improved handling of '#' inside of data URIs
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 browsers right now. If browsers had already converged on correct (strict) parsing behavior, I wouldn't be making this proposal. ~Daniel
