Re: [whatwg] A mask= advisory flag for link rel=icon
On Thu, Jun 25, 2015 at 7:24 AM, Daniel Holbert dholb...@mozilla.com wrote: 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. FWIW, here’s the relevant Chromium issue: https://code.google.com/p/chromium/issues/detail?id=294179
Re: [whatwg] Using @type on code to specify the computer language
There is a de facto standard here that is already supported by most syntax highlighting libraries, based on this part of the spec: https://html.spec.whatwg.org/multipage/semantics.html#the-code-element “There is no formal way to indicate the language of computer code being marked up. Authors who wish to mark code elements with the language used, e.g. so that syntax highlighting scripts can use the right rules, can use the class attribute, e.g. by adding a class prefixed with language- to the element.” I’d prefer following that pattern over inventing a new one.
Re: [whatwg] Unicode - ASCII copy/paste fallback
On Fri, Feb 13, 2015 at 1:18 PM, James M. Greene james.m.gre...@gmail.com wrote: In this case, you can use Unicode escape values by preceding them with a slash: OP’s question wasn’t about how to escape non-ASCII characters, but rather about what the copy/paste behavior should be in browsers. @David, I don’t think it’s reasonable to expect non-ASCII characters to be transliterated to ASCII characters copying them. That said, it would be nice to standardize on the behavior here: should generated content be included when copying or not?
Re: [whatwg] getting rid of anonymizing redirects
On Tue, Oct 7, 2014 at 2:06 PM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Oct 7, 2014 at 1:58 PM, Peter Lepeska bizzbys...@gmail.com wrote: Some web site developers use redirects to strip out referrer headers from requests issued from users clicking links on their site. This causes a blocking round trip and so has a really big impact on web performance. Can we give developers an alternative to this technique that will not incur a performance penalty? For instance, can linkable elements support a ³no-referrer² attribute or something similar? https://html.spec.whatwg.org/multipage/semantics.html#link-type-noreferrer http://w3c.github.io/webappsec/specs/referrer-policy/ There’s also `meta name=referrer content=…`: https://wiki.whatwg.org/wiki/Meta_referrer
Re: [whatwg] Canonical Image and Color
On Tue, Aug 26, 2014 at 8:21 AM, Anne van Kesteren ann...@annevk.nl wrote: On Mon, Aug 25, 2014 at 8:59 PM, Mike tomshin...@yandex-team.ru wrote: 2) There is already a couple of standards or quasi-standads: - favicons (most promising seems to be the increasing of their size and svg support) - apple-touch-icon used by Apple and Android - msapplication-TileImage used by MS - Firefox OS icon (detached case) - SpeedDial API by Opera (as an extension) There's also link rel=icon, which is the way to do this. Sure, but what about the “notification counter” use case that Mike outlined?
Re: [whatwg] apple-touch-icon
On Wed, Jul 30, 2014 at 11:13 AM, Anne van Kesteren ann...@annevk.nl wrote: That would mean http://annevankesteren.com/robots.txt cannot have an icon, unless we revive the Link header somehow, but there wasn't much interest in that. Actually, there is now, at least on Google’s side, in the context of Navigation Transitions. https://docs.google.com/a/chromium.org/document/d/17jg1RRL3RI969cLwbKBIcoGDsPwqaEdBxafGNYGwiY4/edit (read comments) https://code.google.com/p/chromium/issues/detail?id=58456#c7
Re: [whatwg] apple-touch-icon
On Mon, Jul 28, 2014 at 4:59 PM, John Mellor joh...@google.com wrote: Chrome 30 dropped support[1] for fetching apple-touch-icon-* from well known URLs, since the 404 pages that are usually returned were consuming 3-4% of all mobile bandwidth usage[2]. We're unlikely to reverse that. Good to know – thanks! We still support apple-touch-icon-* via link rel under some circumstances (e.g. for add to homescreen), but they're deprecated[3], since we'd like authors to use the standard for this, i.e.: link rel=shortcut icon sizes=128x128 href=/favicon.png There’s no need for `shortcut` there as per the standard.
Re: [whatwg] apple-touch-icon
On Sun, Jul 27, 2014 at 1:13 PM, Anne van Kesteren ann...@annevk.nl wrote: For link rel=icon we already define the /favicon.ico fallback. If a page lacks link rel=icon sizes we should probably also look at Apple's proprietary extension here given that it's quite widely adopted. Chrome supports it and there is some work going on in Firefox as well: https://bugzilla.mozilla.org/show_bug.cgi?id=921014 FWIW, Chrome’s intention was to drop support for Apple’s magic file names at some point. https://developer.chrome.com/multidevice/android/installtohomescreen#icon But I agree — it seems that this won’t happen any time soon. In case it helps, here’s some more info on touch icon support on various OS/devices: http://mathiasbynens.be/notes/touch-icons
Re: [whatwg] brand-color meta extension
On 26 Jun 2014, at 20:45, Domenic Denicola dome...@domenicdenicola.com wrote: I would like to reiterate that brand- is not a good prefix for this purpose. It has nothing to do with brands, and much more to do with the app or with system integration. Major +1 here, seeing as this feedback was ignored before. Just `color` is simpler and makes much more sense. Interesting to see this would be only the second HTML attribute value to get parsed as a simple color (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#simple-color) rather than a legacy color (the other one being `input type=color value=foo`).
Re: [whatwg] brand-color meta extension
On 26 Jun 2014, at 22:37, Tab Atkins Jr. jackalm...@gmail.com wrote: On Thu, Jun 26, 2014 at 1:33 PM, Mathias Bynens mathi...@opera.com wrote: On 26 Jun 2014, at 22:24, Mathias Bynens mathi...@opera.com wrote: Interesting to see this would be only the second HTML attribute value to get parsed as a simple color (http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#simple-color) rather than a legacy color (the other one being `input type=color value=foo`). Actually, the way it’s currently specced it wouldn’t be a parsed as a simple color value nor as a legacy color value. It should probably be one or the other (rather than introducing a third, new way to parse color values). https://github.com/whatwg/meta-brand-color/issues/1 Well, the third way is as CSS, which already exists in the platform. Parsing a legacy color value is also “as CSS”, with some extra fallback logic in case that fails (which is currently undefined in the `brand-color` spec), and this logic is already used for the majority of HTML attributes that represent a color value.
Re: [whatwg] HTTP status code from JavaScript
On 25 May 2014, at 09:58, Tobie Langel tobie.lan...@gmail.com wrote: * Adding inline JS script slows down the page load. In that case, use a meta tag: meta name=http-status content=404 Then in JS: var status = parseInt(document.querySelector(meta[name=http-status]).getAttribute(content)); Since `http-status` is not a registered metadata name (http://wiki.whatwg.org/wiki/MetaExtensions) it might be better to use a custom `data-*` attribute. It could be added to any element, e.g. body data-http-status=404 Then in JavaScript: var status = Number(document.body.dataset.httpStatus);
Re: [whatwg] Proposal: Adding methods like getElementById and getElementsByTagName to DocumentFragments
On 10 Oct 2013, at 15:05, Simon Pieters sim...@opera.com wrote: I've added CSS.escape(foo). https://dvcs.w3.org/hg/csswg/rev/09466af95185 Very useful, thanks. Here’s a polyfill for `CSS.escape`: https://github.com/mathiasbynens/CSS.escape Tests: https://github.com/mathiasbynens/CSS.escape/blob/master/tests/tests.js
Re: [whatwg] [JavaScript / Web ECMAScript] Dropping the “escaped reserved words” compatibility requirement
Following the discussion in #whatwg and on https://bugzilla.mozilla.org/show_bug.cgi?id=744784 and https://bugs.ecmascript.org/show_bug.cgi?id=277, I’ve filed the following bugs asking to remove this non-standard extension as there don’t seem to be any strong compatibility requirements: * Opera/Carakan: https://bugs.opera.com/browse/DSK-369398 * Chrome/V8: http://code.google.com/p/v8/issues/detail?id= * Safari/JavaScriptCore: https://bugs.webkit.org/show_bug.cgi?id=90678
[whatwg] [JavaScript / Web ECMAScript] Dropping the “escaped reserved words” compatibility requirement
http://mathias.html5.org/specs/javascript/#escaped-reserved-words says: JavaScript implementations must support ECMAScript identifiers that unescape to a reserved word, as long as at least one character is escaped using a Unicode escape sequence. For example, var var; throws a syntax error, but e.g. var v\u0061r; works fine. Subsequent use of such identifiers must also have at least one character escaped (otherwise the reserved word will be used instead), but it doesn’t have to be the same character(s) that were originally used to create the identifier. For example, var v\u0061r = 42; alert(va\u0072); alerts 42. One year ago, all browsers except IE fulfilled this compatibility requirement. Half a year ago Firefox dropped this non-standard addition (https://bugzilla.mozilla.org/show_bug.cgi?id=694360) and hasn’t seen any compatibility issues since. Has the time come to drop this compatibility requirement?
