Re: [whatwg] A mask="" advisory flag for

map for every iOS device specifically (when we add to homepage)? Do > chrome and Firefox support SVG icon images? > On 24 Jun 2015 2:40 pm, "Tab Atkins Jr." wrote: > >> On Wed, Jun 24, 2015 at 2:36 PM, Maciej Stachowiak wrote: >>> To close the loop on this, we will c

Re: [whatwg] A mask="" advisory flag for

automatic color picking based on the SVG as a fallback when the color is missing as a future extension. Please let me know if anyone disagrees with this approach. Regards, Maciej > On Jun 17, 2015, at 3:32 PM, Maciej Stachowiak wrote: > > > >> >>> Out of curiosity, I

Re: [whatwg] A mask="" advisory flag for

> On Jun 17, 2015, at 12:42 PM, Benjamin Francis wrote: > > On 17 June 2015 at 20:23, Maciej Stachowiak wrote: > >> Using a mask attribute in place of href would solve the compat problem >> about as well as using rel=“mask-icon”, but it seems kind of weird to me. >

Re: [whatwg] A mask="" advisory flag for

> >> Out of curiosity, I understand that flat design is fashionable right now >> and you might want single colour icons to represent web sites in Safari, >> but what is your fallback for the billion or so web sites which currently >> only provide a multi-coloured icon? I assume you just display t

Re: [whatwg] A mask="" advisory flag for

Consolidating replies... > On Jun 17, 2015, at 7:03 AM, Benjamin Francis wrote: > > Personally I would recommend using the web manifest for your use case, > something like this: We can look into that in the future, but even if we had it right now, I’m not sure that’s a reason to not have t

Re: [whatwg] A mask="" advisory flag for

t; given in this thread; if you're seeking a rubberstamp rather than a >> collab, say so. > > Maciej already clarified this, no? They're perfectly happy to change > this before Safari 9 ships, provided, I'm guessing, that we settle > this somewhat quickly. Yep. Quoting

Re: [whatwg] Icon mask and theme color

Consolidating replies to limit spam. > On Jun 16, 2015, at 4:37 AM, Nils Dagsson Moskopp > wrote: > > Maciej Stachowiak writes: > >> […] >> >> Where do we go from here: >> (1) We could add "mask" or something like it to the standard, and cha

Re: [whatwg] A mask="" advisory flag for

There’s no technological enforcement that the SVG only uses the color black. We will interpret it as a mask in the same way as the SVG ‘mask’ element, which effectively combines the luminance with the alpha channel. Effectively, this means that other colors will end up partly transparent, so us

Re: [whatwg] A mask="" advisory flag for

ike that instead of "mask", since mask is too generic a term. - Maciej > > Justin > > On Mon, Jun 15, 2015 at 4:20 PM, Maciej Stachowiak wrote: > >> >>> On Jun 15, 2015, at 3:55 PM, Elliott Sprehn >> wrote: >>> >>> Adding a

Re: [whatwg] A mask="" advisory flag for

> On Jun 15, 2015, at 3:55 PM, Elliott Sprehn wrote: > > Adding a whole new attribute for this seems like overkill, why not use the > rel. > > > > That's what the rel list was designed for. In general, rel values are supposed to be orthogonal, they should not modify each other’s meanings. r

Re: [whatwg] Icon mask and theme color

> On Jun 15, 2015, at 3:27 AM, Anne van Kesteren wrote: > > On Mon, Jun 15, 2015 at 12:18 PM, Kornel Lesiński wrote: >> The new Safari is still only a preview, so I hope Apple will switch to a >> better solution. > > It would be great if we could get some feedback from Ted & colleagues > on w

Re: [whatwg] Proposal: requestBackgroundProcessing()

> On Feb 20, 2014, at 9:01 AM, Boris Zbarsky wrote: > >> On 2/20/14 11:18 AM, Tab Atkins Jr. wrote: >> (If people used rAF for what it was *intended* for, we could probably >> have stopped firing it *entirely* when the window isn't visible. > > We do. At least Chrome and Firefox do. Safari t

Re: [whatwg] Simplified element draft

On Dec 31, 2013, at 7:17 AM, Yoav Weiss wrote: > On Mon, Nov 25, 2013 at 5:33 PM, Adam Barth wrote: > >> Is there an editor's draft or some other relatively self-contained >> write-up that I could review? >> >> > Tab has rewritten the picture spec to match the latest proposal. You could > re

Re: [whatwg] responsive imgs proposition (Re: The src-N proposal)

ld let the image URLs be in the markup but the media queries in un-repeated CSS? Regards, Maciej > > laurent > > > > On Tue, Nov 19, 2013 at 2:19 AM, Tab Atkins Jr. wrote: > >> On Mon, Nov 18, 2013 at 5:08 PM, Maciej Stachowiak wrote: >>> I see. It seems like it w

Re: [whatwg] Add "Switch" Type

On Nov 19, 2013, at 1:37 AM, Jonas Sicking wrote: > Realistically speaking, I don't think this will help much at all. Few > websites like using the default styling for form controls anyway and > so people would be just as unhappy with the default switch rendering > as they are with the default c

Re: [whatwg] responsive imgs proposition (Re: The src-N proposal)

On Nov 18, 2013, at 2:54 PM, Tab Atkins Jr. wrote: > On Mon, Nov 18, 2013 at 1:35 PM, Maciej Stachowiak 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: &

Re: [whatwg] responsive imgs proposition (Re: The src-N proposal)

On Nov 18, 2013, at 9:05 AM, Tab Atkins Jr. wrote: > On Sun, Nov 17, 2013 at 3:11 PM, Maciej Stachowiak 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 legac

Re: [whatwg] The src-N proposal

On Nov 16, 2013, at 11:30 AM, Tab Atkins Jr. wrote: > On Sat, Nov 16, 2013 at 10:54 AM, Timothy Hatcher wrote: >> My objections were mostly about semantics and not purely aesthetic. I also >> wasn't the only one to raise concerns on webkit-dev. To represent the WebKit >> community concerns as

Re: [whatwg] responsive imgs proposition (Re: The src-N proposal)

On Nov 15, 2013, at 3:00 PM, Tab Atkins Jr. wrote: > On Fri, Nov 15, 2013 at 12:39 PM, Adam Barth wrote: >> Do you have an alternative proposal aside from src-N? Recall that >> src-N has been rejected by WebKit and therefore is no longer viable. > > Hey, WebKit, what's your answer if we just

Re: [whatwg] responsive imgs proposition (Re: The src-N proposal)

On Nov 15, 2013, at 9:00 AM, Yoav Weiss wrote: > On Fri, Nov 15, 2013 at 4:20 PM, Adam Barth wrote: > >> >> My apologies. I thought Christian Biesinger addressed all these >> concerns with his proposal: >> >> On Tue, Nov 12, 2013 at 5:56 PM, Christian Biesinger >> wrote: >>> For a bit more

Re: [whatwg] responsive imgs proposition (Re: The src-N proposal)

On Nov 12, 2013, at 9:50 AM, Adam Barth wrote: > On Tue, Nov 12, 2013 at 9:22 AM, Markus Ernst wrote: >> Am 12.11.2013 17:48 schrieb Markus Lanthaler: >>> On Tuesday, November 12, 2013 5:04 PM, Markus Ernst wrote: > > We could define some ways to list set of images that could be

Re: [whatwg] The src-N proposal

On Nov 10, 2013, at 12:20 AM, Adam Barth wrote: > On Fri, Nov 8, 2013 at 11:46 AM, Ian Hickson wrote: >> On Fri, 8 Nov 2013, Rafael Rinaldi wrote: >>> It looks complex because it tries to solve something complex. I think >>> there’s no way to avoid verbosity to solve such thing. >> >> The way

Re: [whatwg] The src-N proposal

On Nov 8, 2013, at 11:46 AM, Ian Hickson wrote: > On Fri, 8 Nov 2013, Rafael Rinaldi wrote: >> >> It looks complex because it tries to solve something complex. I think >> there’s no way to avoid verbosity to solve such thing. > > The way you avoid complexity in such things is that you don't s

Re: [whatwg] Proposal: Loading and executing script as quickly as possible using multipart/mixed

On Dec 3, 2012, at 11:19 PM, Adam Barth wrote: > On Mon, Dec 3, 2012 at 9:57 PM, Maciej Stachowiak wrote: >> On Dec 3, 2012, at 2:11 PM, William Chan (陈智昌) wrote: >>> Unless I am misunderstanding, SPDY will not solve this problem. SPDY uses >>> prioritized multipl

Re: [whatwg] Proposal: Loading and executing script as quickly as possible using multipart/mixed

It might be good to use a custom MIME type instead of multipart/mixed. multipart/mixed can represent arbitrary heterogenous sequences of types, which is not the desired semantic here - you want a sequence of all text/javascript types. It also has a syntactic affordance for conveying a MIME type

Re: [whatwg] Proposal: Loading and executing script as quickly as possible using multipart/mixed

On Dec 3, 2012, at 2:11 PM, William Chan (陈智昌) wrote: > Unless I am misunderstanding, SPDY will not solve this problem. SPDY uses > prioritized multiplexing of streams. It seems to me like SPDY could make this case work better: Specifically the individual script chunks could be ordered an

Re: [whatwg] proposal for a location.domain property

On Nov 29, 2012, at 4:31 AM, Anne van Kesteren wrote: > On Sat, May 26, 2012 at 3:58 AM, Maciej Stachowiak wrote: >> I don't think location.domain would be the same as location.tld, to the >> extent I understand the intent of them. >> For the URL "http://www.app

Re: [whatwg] Improving autocomplete

(1) If this API fills in a form completely based on stored data, and not by completing the user's typing, then it is "autofill" rather than "autocomplete". (2) If this API provides the ability to get user information without even having a visible form, then it's not clear that it is even really

Re: [whatwg] A plea to Hixie to adopt

On Nov 7, 2012, at 8:52 AM, Ojan Vafai wrote: > On Wed, Nov 7, 2012 at 6:23 AM, Simon Pieters wrote: > >> My impression from TPAC is that implementors are on board with the idea of >> adding to HTML, and we're left with Hixie objecting to it. >> > > For those of use who couldn't make it, wh

Re: [whatwg] Features for responsive Web design

On Oct 11, 2012, at 11:07 AM, Markus Ernst wrote: > Am 11.10.2012 18:36 schrieb Ian Hickson: >> On Thu, 11 Oct 2012, Markus Ernst wrote: >>> >>> IMHO as an author, the "bandwidth" use case is not solved in a future >>> proof manner >> >> It's not solved at all. I didn't attempt to solve it. Be

Re: [whatwg] Features for responsive Web design

On Oct 10, 2012, at 1:14 AM, Maciej Stachowiak wrote: > > On Oct 9, 2012, at 2:49 PM, Tab Atkins Jr. wrote: > >> On Tue, Oct 9, 2012 at 11:48 AM, Ian Hickson wrote: >>> On Tue, 9 Oct 2012, Mark Callow wrote: >>>> On 2012/10/06 7:09, Ian Hickson wrote: >

Re: [whatwg] Features for responsive Web design

On Oct 9, 2012, at 2:49 PM, Tab Atkins Jr. wrote: > On Tue, Oct 9, 2012 at 11:48 AM, Ian Hickson wrote: >> On Tue, 9 Oct 2012, Mark Callow wrote: >>> On 2012/10/06 7:09, Ian Hickson wrote: I agree, when there's 3x displays, this could get to the point where we need to solve it. :-) >>

Re: [whatwg] [canvas] Path object

Charles, Your whole message here is bizarre and disruptive: - Your claims about the data gathering capabilities of varying browser vendors are arbitrary, incorrect (in the cases I know of), and off-topic for this list. - Your reference to "the Hixie-Atkins draft" is unwarranted and strange. - T

Re: [whatwg] [canvas] Path object

Can we get data on prevalence of such pages? - Maciej On Oct 2, 2012, at 4:58 PM, Elliott Sprehn wrote: > What of the fact that this breaks existing pages with id="Path"> that access it as just Path? Historically this has been a > non-starter for new APIs. > > On Tue, Oct 2, 2012 at 3:00 PM

Re: [whatwg] New URL Standard

Excellent work. Did you use tests while making this and if so did you save them? It might be worthwhile to check all the browsers against the spec. Cheers, Maciej On Sep 21, 2012, at 8:16 AM, Anne van Kesteren wrote: > I took a crack at defining URLs: http://url.spec.whatwg.org/ > > At the

Re: [whatwg] Features for responsive Web design

On Sep 5, 2012, at 12:07 AM, Fred Andrews wrote: > ... > >>> I have always been comfortable with the 'x' part of srcset, but the w >>> and h part felt somewhat wrong to me. What you'd really want to consider >>> when deciding which image to pick isn't the size of the viewport itself, >>> but

Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts

r. Cheers, Maciej On Aug 27, 2012, at 11:23 PM, Maciej Stachowiak wrote: > > Someone earlier in the thread mentioned that this feature sounds an awful lot > like rel=noreferrer, which has been in WebKit for several years: > http://www.webkit.org/blog/907/webkit-nightlies-support

Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts

I overlooked that it's also in the spec itself, not just the registry: http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-noreferrer Regards, Maciej On Aug 27, 2012, at 11:23 PM, Maciej Stachowiak wrote: > > Someone earlier in the thread mentione

Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts

Someone earlier in the thread mentioned that this feature sounds an awful lot like rel=noreferrer, which has been in WebKit for several years: http://www.webkit.org/blog/907/webkit-nightlies-support-html5-noreferrer-link-relation/ It is also mentioned in the official link relation registry: http

Re: [whatwg] Feedback on Web Worker specification

To expand a little on rationale for what Jeffrey said: We're working on an experimental preference setting for WebKit to block data storage in a third-party context, similar to the third-party cookie blocking feature in many browsers, but covering all forms of client-side storage. The intent o

Re: [whatwg] register*Handler and Web Intents

I also agree with Henri and James. I would be opposed to implementing the feature in WebKit the way it is currently proposed. The aesthetic benefit is not great enough to be worth the breakage. Consider in particular that the following proposed markup: could just as easily be: or:

Re: [whatwg] alt="" and the exception

On Aug 7, 2012, at 9:53 AM, Michael[tm] Smith wrote: > > Anyway, do you have a concrete suggestion for an alternate name? I'm not > wedded to "generator-unable-to-provide-required-alt" and I doubt Hixie is > either. It's just a proposal that came up after 15 minutes of brainstorming > on IRC. T

[whatwg] Missing alt attribute name bikeshedding (was Re: alt="" and the exception)

On Aug 1, 2012, at 12:56 AM, Ian Hickson wrote: > > We briefly brainstormed some ideas on #whatwg earlier tonight, and one > name in particular that I think could work is the absurdly long > > > > This has several key characteristics that I think are good: > > - it's long, so people aren

Re: [whatwg] A mechanism to improve form autofill

On Jul 25, 2012, at 11:21 PM, Aryeh Gregor wrote: > > > I would also like to point out that this feature seems to overlap with > not only type="" (as has been pointed out), but inputmode="" as well, > and for that matter pattern="". I think it would be quite unfortunate > if authors found the

Re: [whatwg] A mechanism to improve form autofill

On Jul 25, 2012, at 12:36 PM, Anne van Kesteren wrote: > On Wed, Jul 25, 2012 at 8:54 PM, Maciej Stachowiak wrote: >> For some of these fields, autocomplete="" as a hint to autocompletion seems >> sufficient. However, I think some may logically be a distinct input ty

Re: [whatwg] A mechanism to improve form autofill

On Jul 23, 2012, at 4:41 PM, Ian Hickson wrote: > > On Thu, 26 Jan 2012, Kornel LesiÅ~Dski wrote: >> >> But even if single-mixed-login-field autocomplete was desired, then >> perhaps a mixed type would work too: >> >> >> >> How about merging autocompletetype with autocomplete then? >> >>

Re: [whatwg] isPointInPath v. set of pixels in canvas hit regions

On Jul 5, 2012, at 11:28 PM, Tab Atkins Jr. wrote: > On Thu, Jul 5, 2012 at 1:05 PM, Edward O'Connor wrote: >> As things currently stand in the spec, implementations basically need to >> keep N+1 bitmaps per canvas, where N is the number of hit regions. I >> doubt any implementors would be enth

Re: [whatwg] make always focusable and interactive content

On Jun 19, 2012, at 8:43 PM, Silvia Pfeiffer wrote: > Hi all, > > I recently experimented with keyboard accessibility of media elements. > > I found that browsers don't provide a default tabfocus on media > elements nor do they provide keyboard interactivity. I had to put > explicit @tabindex

Re: [whatwg] AllowSeamless

On May 26, 2012, at 5:16 PM, Adam Barth wrote: > Hi whatwg, > > I've added a proposal to the wiki > about letting a document > indicate that it is willing to be displayed seamlessly with a > cross-origin parent. This proposal is a refinement of the a

Re: [whatwg] The set of supported @type values for

On May 25, 2012, at 10:03 AM, Boris Zbarsky wrote: > The list is at > http://www.whatwg.org/specs/web-apps/current-work/multipage/scripting-1.html#support-the-scripting-language > or http://dev.w3.org/html5/spec/the-script-element.html#scriptingLanguages > depending on which you prefer to rea

Re: [whatwg] proposal for a location.domain property

On May 25, 2012, at 4:27 AM, João Eiras wrote: > On Thu, 24 May 2012 23:02:00 +0200, Maciej Stachowiak wrote: > >> >> I agree. Even though there are still legacy features like cookies and >> document.domain that use domain-based security, most of the Web platfo

Re: [whatwg] proposal for a location.domain property

I agree. Even though there are still legacy features like cookies and document.domain that use domain-based security, most of the Web platform uses origin-based security, and that has proved to be a sounder model. While I acknowledge the use cases for exposing location.domain, it's also likely

Re: [whatwg] Make files attribute of the input element writable

On May 22, 2012, at 11:57 PM, Adam Barth wrote: > On Tue, May 22, 2012 at 9:16 PM, Maciej Stachowiak wrote: >> It seems like making FileList mutable would serve the same use case and >> would also be more flexible (as you could upload a set of files collected >> f

Re: [whatwg] Make files attribute of the input element writable

It seems like making FileList mutable would serve the same use case and would also be more flexible (as you could upload a set of files collected from possibly multiple sources). And it seems like adding is a more likely desired behavior than replacing when dragging files onto a multi-file inpu

Re: [whatwg] Features for responsive Web design

On May 21, 2012, at 9:37 PM, Kornel Lesiński wrote: > > >> There’s no prior precedent this sort of thing—there’s no reason we can’t >> find a way to preserve an image’s intrinsic width using `picture`. I wonder >> if simply adding `width` and `height` attributes on the element (similar to >

Re: [whatwg] Bandwidth media queries

On May 20, 2012, at 6:13 AM, Boris Zbarsky wrote: > On 5/20/12 9:04 AM, Boris Zbarsky wrote: >> On 5/20/12 5:45 AM, Paul Irish wrote: >>> Since no one mentioned it, I just wanted to make sure this thread is >>> aware >>> of the Network Information API [1], which provides >>> navigator.connection

Re: [whatwg] Features for responsive Web design

On May 18, 2012, at 3:16 AM, Markus Ernst wrote: > Am 15.05.2012 09:28 schrieb Ian Hickson: >>> srcset="face-600-...@1.jpeg 600w 200h 1x, >> face-600-...@2.jpeg 600w 200h 2x, >> face-icon.png 200w 200h"> > > Re-reading most parts of the last day

Re: [whatwg] Defaulting new image solution to 192dpi

On May 17, 2012, at 12:20 PM, Kornel Lesiński wrote: > On Thu, 17 May 2012 19:32:51 +0100, Jeremy Keith wrote: > >> Kornel wrote: >>> Note that the scale multiplier can be omitted already when only the size is >>> specified >> >> I'm confused by what you mean by scale multiplier. The x value

Re: [whatwg] Correcting some misconceptions about Responsive Images

On May 17, 2012, at 11:20 AM, Matthew Wilcox wrote: > On 17 May 2012 19:15, Tab Atkins Jr. wrote: >> On Thu, May 17, 2012 at 11:12 AM, Matthew Wilcox >> wrote: A few humble thoughts -Have the CG recruit an experienced implementor or editor to participate more or less from

Re: [whatwg] Correcting some misconceptions about Responsive Images

On May 16, 2012, at 10:39 PM, Jonas Sicking wrote: > > I agree that there's no obligation. And I agree that if people here > didn't know about the existence of the CG then of course it's not > surprising that we didn't engage with the work that was happening > there. > > However I was under th

Re: [whatwg] Features for responsive Web design

On May 16, 2012, at 9:39 PM, Silvia Pfeiffer wrote: > On Wed, May 16, 2012 at 10:55 PM, Matthew Wilcox > wrote: >> Chalk me up as another making that mistake. Properties on elements >> usually describe a property of the element. Not a property of >> something else (like the viewport). > > If

Re: [whatwg] Correcting some misconceptions about Responsive Images

On May 16, 2012, at 4:53 PM, Jonas Sicking wrote: > On Wed, May 16, 2012 at 1:59 PM, Anne van Kesteren wrote: >> I just wanted to correct one small thing here. >> >> On Wed, May 16, 2012 at 10:51 PM, Jonas Sicking wrote: >>> (The difference that the w3c lists were private is not really a >>>

Re: [whatwg] So if media-queries aren't for determining the media to be used what are they for?

On May 15, 2012, at 3:06 PM, Chris Heilmann wrote: > I also wonder what we do with videos? Surely they have the same issues and > there is no proposal for changing the syntax there. With current codecs, and given human perception of visual images, videos can be decoded at multiple resolutions

Re: [whatwg] Features for responsive Web design

On May 15, 2012, at 8:06 AM, Tab Atkins Jr. wrote: > On Tue, May 15, 2012 at 9:28 AM, Ian Hickson wrote: >> On Thu, 10 May 2012, Tab Atkins Jr. wrote: >> >> 3.125x isn't particularly difficult to specify. > > I actually didn't even realize that 300dpi is 3.125 times 96dpi. > > Regardless, I

Re: [whatwg] , `img set`, and polyfills

On May 14, 2012, at 4:17 PM, Mathew Marquis wrote: > It’s worth noting that a practical polyfill may not be possible when using > `img set`, for reasons detailed at length elsewhere: > http://www.alistapart.com/articles/responsive-images-how-they-almost-worked-and-what-we-need/ > http://www.net

Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)

On May 12, 2012, at 5:33 PM, Mathew Marquis wrote: > I worry that, when faced with this markup, developers will simply opt to > serve the largest possible image in a src. In fairness, that approach "works" > with far less headache. For the resolution-adaptation use case, that wouldn't do the

Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)

On May 12, 2012, at 12:35 PM, Adam Barth wrote: > On Sat, May 12, 2012 at 11:17 AM, Maciej Stachowiak wrote: >> >> On May 12, 2012, at 6:28 AM, Mathew Marquis wrote: >> >>> While that information may be available at the time the img tag is parsed, >>&g

Re: [whatwg] Implementation complexity with elements vs an attribute (responsive images)

On May 12, 2012, at 6:28 AM, Mathew Marquis wrote: > While that information may be available at the time the img tag is parsed, I > don’t believe it will be available at the time of prefetching — I’m happy to > research this further and report back with citations. I’m sure I don’t have > to t

Re: [whatwg] Proposal in supporting the writing of "Arabizi"

On May 10, 2012, at 12:00 PM, Sami Eljabali wrote: > Good luck pushing Apple & Microsoft in implementing this. If we create this > as a tag then we'd push every OS vendor to support it. Mac OS X supports "Arabic", "Arabic - PC" and "Arabic - QWERTY" input methods. If none of these provide the

Re: [whatwg] for responsive bitmapped content images

On May 10, 2012, at 7:26 AM, Boris Zbarsky wrote: > On 5/10/12 10:19 AM, Mathew Marquis wrote: >> Hey guys. Don’t know if it’s too early to chime in with this, but we were >> told by some members of the Chrome team that any browser that supports DNS >> prefetching — including assets — wouldn’t

Re: [whatwg] for responsive bitmapped content images

On May 10, 2012, at 6:47 AM, Simon Pieters wrote: > On Thu, 10 May 2012 15:24:28 +0200, Tab Atkins Jr. > wrote: > >> For two, I'm not sure that it's particularly obvious that when you say >> "2x", you should make sure your image was saved as 196dpi. You have >> to already know what the defau

Re: [whatwg] for responsive bitmapped content images

On May 10, 2012, at 6:24 AM, Tab Atkins Jr. wrote: > > > That all said, I don't like the "2x" notation. It's declaring "this > image's resolution is twice that of a normal image". This has two > problems. For one, we already have a unit that means that - the dppx > unit. Using "2dppx" is i

Re: [whatwg] Footer inside header

On Apr 26, 2012, at 9:39 AM, Tab Atkins Jr. wrote: > On Thu, Apr 26, 2012 at 1:32 AM, Benjamin Hawkes-Lewis > wrote: >> On Apr 25, 2012 9:20 PM, "Andrés Sanhueza" wrote: >>> I see no reason a >>> as in "textual metadata of a section" can't be inside a >>> ("lead of a section"). Could this be

Re: [whatwg] Request for new DOM property textarea.selectionText

On Apr 29, 2012, at 1:41 PM, David Young wrote: > On Sun, Apr 29, 2012 at 10:38:26AM +0300, Aryeh Gregor wrote: >> On Sun, Apr 29, 2012 at 10:29 AM, Ryosuke Niwa wrote: >>> That sounds like a tangential issue. We can easily extend execCommand to >>> support arbitrary range(s) since such a featu

Re: [whatwg] Request for new DOM property textarea.selectionText

Does this work in any non-WebKit browsers? (Asking mainly out of curiosity; I would tend to agree in any case that adding nontrivial editing APIs that are specific to only plaintext editable controls is not a good idea. But it might be nice to specify explicitly whether execCommand works on for

Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio

On Apr 22, 2012, at 7:10 PM, Glenn Maynard wrote: > On Sun, Apr 22, 2012 at 8:03 PM, Maciej Stachowiak wrote: > All JavaScript that runs on the main thread has the potential to "freeze the > UI for all pages sharing that thread". > > APIs on the main thread are design

Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio

On Apr 20, 2012, at 6:53 AM, Glenn Maynard wrote: > On Thu, Apr 19, 2012 at 11:28 PM, Maciej Stachowiak wrote: > You could also address this by adding a way to be notified when the contents > of an ImageData are available without blocking. That would work with both > vanilla getI

Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio

On Apr 17, 2012, at 3:32 PM, Darin Fisher wrote: > > ^^^ This got me thinking... > > In Chrome at least, getImageData() doesn't actually block to fetch pixels. > The thread is only blocked when the first dereference of the pixel buffer > occurs. I believe this is done so that a getImageData(

Re: [whatwg] Proposal for non-modal versions of modal prompts

On Apr 16, 2012, at 1:52 PM, Darin Fisher wrote: > > > On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak wrote: > > On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote: > >> >> >> On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak wrote: >> >>

Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio

On Apr 16, 2012, at 12:10 PM, Glenn Maynard wrote: > On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt wrote: > I don't understand why adding a runloop cycle to any read seems like > something that would introduce a much more noticable delay than a memcopy. > > The use case is deferred rendering.

Re: [whatwg] Proposal for non-modal versions of modal prompts

On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote: > > > On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak wrote: > > On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote: > > > > > will give a better user experience than even a non-modal version > >

Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio

On Mar 21, 2012, at 8:31 PM, Charles Pritchard wrote: > On 3/21/2012 8:21 PM, Maciej Stachowiak wrote: >> On Mar 20, 2012, at 3:22 PM, Charles Pritchard wrote: >> >>> On Mar 20, 2012, at 3:05 PM, Edward O'Connor wrote: >>> >>>> Charles Prit

Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio

On Mar 20, 2012, at 12:00 PM, James Robinson wrote: > If we are adding new APIs for manipulating the backing directly, can we > make them asynchronous? This would allow for many optimization > opportunities that are currently difficult or impossible. Neat idea to offer async backing store access

Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio

On Mar 20, 2012, at 3:22 PM, Charles Pritchard wrote: > On Mar 20, 2012, at 3:05 PM, Edward O'Connor wrote: > >> Charles Pritchard wrote: >> But now run through this logic when the is making a high res backing store automatically: by doing the clever thing, you're now quadrupli

Re: [whatwg] Proposal for non-modal versions of modal prompts

On Mar 20, 2012, at 6:04 PM, Boris Zbarsky wrote: > On 3/20/12 6:50 PM, Adam Barth wrote: >> I'm not sure addresses the same use cases as alert() and >> confirm() because is significantly more complicated. > > But also allows for much better UX... > >> >> Are you sure you want to order the w

Re: [whatwg] Proposal for non-modal versions of modal prompts

On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote: > > will give a better user experience than even a non-modal version of > window.confirm() or window.alert(). Dialogs that are fully in-page Oops, got cut off here. What I meant to say is something like "dialogs that are

Re: [whatwg] Proposal for non-modal versions of modal prompts

On Mar 20, 2012, at 3:50 PM, Adam Barth wrote: > On Mon, Mar 19, 2012 at 2:20 PM, Ian Hickson wrote: >> On Mon, 19 Mar 2012, Jochen Eisinger wrote: >>> I'd like to put forward a proposal for extending the modal prompts >>> (alert/confirm/prompt) with an optional callback parameter. If the >>> op

[whatwg] Meta Referrer

Hi Folks, What is the plan (if any) for turning Meta Referrer into a standard? Currently there's a wiki spec, which is somewhat incomplete and which modifies the middle of the HTML Fetch algorithm (probably not a future-proof approach, since it refers to a numbered step): http://wiki.whatwg

Re: [whatwg] Full Screen API Feedback

On May 13, 2011, at 10:01 PM, Robert O'Callahan wrote: > On Fri, May 13, 2011 at 8:52 PM, Maciej Stachowiak wrote: > Limited or no keyboard input also greatly mitigates the risk of a full OS UI > spoofing attack. I think there are better ways to address this than prompting &

Re: [whatwg] Full Screen API Feedback

On May 13, 2011, at 12:46 AM, Henri Sivonen wrote: > On Thu, 2011-05-12 at 20:29 -0400, Aryeh Gregor wrote: >> In >> particular, Flash has allowed this for years, with 95%+ penetration >> rates, so we should already have a good idea of how this feature can >> be exploited in practice. > > I don'

Re: [whatwg] Can we make checkboxes readonly?

On Apr 6, 2011, at 3:46 PM, Tab Atkins Jr. wrote: > On Wed, Apr 6, 2011 at 3:39 PM, Lachlan Hunt wrote: >> On 2011-04-07 00:28, Tab Atkins Jr. wrote: >>> >>> On Wed, Apr 6, 2011 at 3:12 PM, Lachlan Hunt >>> wrote: What's wrong with using disabled? >>> >>> Disabled

Re: [whatwg] documentFragment and innerHTML

WebKit already has insertAdjacentHTML support. On Feb 26, 2011, at 4:47 PM, Aryeh Gregor wrote: > On Sat, Feb 26, 2011 at 9:52 AM, Rafael Holt wrote: >> Yes, I had just never heard of insertAdjacentHTML(), since it doesn't enjoy >> Webkit or Gecko support. Once it does though, I agree it's a

Re: [whatwg] Proposal for a tab visibility API

On Dec 8, 2010, at 11:47 AM, Alex Komoroske wrote: > Hi all, > > On the Chromium team we’ve identified a couple of use cases that we’d like to > address with a simple API, and we’d love your feedback. > > In particular, there is currently no good way for a web page to detect that > it is a ba

Re: [whatwg] Video with MIME type application/octet-stream

On Sep 8, 2010, at 8:05 AM, Julian Reschke wrote: > On 07.09.2010 22:00, Boris Zbarsky wrote: >> ... >>> * If a file in a top-level browsing context is sniffed as video but >>> then some kind of error is returned before the video plays the first >>> frame, fall back to allowing the user to downlo

Re: [whatwg] Video with MIME type application/octet-stream

On Sep 7, 2010, at 3:52 AM, Philip Jägenstedt wrote: > On Tue, 07 Sep 2010 11:51:55 +0200, And Clover wrote: > >> On 09/07/2010 03:56 AM, Boris Zbarsky wrote: >> >>> P.S. Sniffing is harder that you seem to think. It really is... >> >> Quite. It surprises and saddens me that anyone wants to a

Re: [whatwg] @srcdoc and default @sandbox

On Aug 31, 2010, at 4:16 PM, Kornel Lesiński wrote: > On 31.08.2010, at 23:39, Tab Atkins Jr. wrote: > > At least as currently drafted, srcdoc is not a security feature. It's a > convenience feature. It is also designed to work well in tandem with a > particular security feature (san

Re: [whatwg] @srcdoc and default @sandbox

On Aug 30, 2010, at 4:11 PM, Tab Atkins Jr. wrote: > On Mon, Aug 30, 2010 at 2:08 PM, Adam Barth wrote: >> On Mon, Aug 30, 2010 at 1:58 PM, Maciej Stachowiak wrote: >>> Should @seamless imply @sandbox too, then? >> >> I think there lots of use cases for seamless

Re: [whatwg] @srcdoc and default @sandbox

On Aug 30, 2010, at 11:27 AM, Tab Atkins Jr. wrote: > On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak wrote: >> >> On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote: >> >>> While talking with the implementor of @srcdoc in Webkit, it came up >>> tha

Re: [whatwg] @srcdoc and default @sandbox

On Aug 30, 2010, at 11:27 AM, Justin Schuh wrote: > On Mon, Aug 30, 2010 at 10:18 AM, Maciej Stachowiak wrote: >> >> I think it's better to let these remain orthogonal features. In general I >> think it is a net negative to usability when Feature A implicitly turns

Re: [whatwg] @srcdoc and default @sandbox

On Aug 30, 2010, at 10:02 AM, Tab Atkins Jr. wrote: > While talking with the implementor of @srcdoc in Webkit, it came up > that, though @srcdoc is *designed* for use with @sandbox, the author > still has to explicitly add @sandbox to the or else they > don't get the sandbox security model. > >

  1   2   3   4   5   6   >