element in the document, plus the white space collapsing behaviour. Do you want to just handle that all in HTML? I'm not sure there's much value to duplicating either the searching for the title element or the white space collapsing behaviour in SVG itself. From cam at mcc.id.au Sat Feb 1 21:28:48 2014 From: cam at mcc.id.au (Cameron McCormack) Date: Sat, 01 Feb 2014 21:28:48 -0800 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <52EDD11A.5030606@mcc.id.au> References: <52EDD11A.5030606@mcc.id.au> Message-ID: <52EDD790.7080303@mcc.id.au> On 1/02/2014 9:01 pm, Cameron McCormack wrote: > Do you want to just handle that all in HTML? I'm not sure there's much > value to duplicating either the searching for the title element or the > white space collapsing behaviour in SVG itself. Oh, and for the setter, it looks like implementations don't do anything when assigning to document.title in SVG documents. (Chrome does something funny where it remembers what you assign to document.title, but it doesn't affect what's in the <title> element.) I don't have a strong opinion on whether we should make the setter do something useful or nothing at all. If we do, any newly created <title> element should be appended to the document element. From dschulze at adobe.com Sat Feb 1 22:01:50 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 2 Feb 2014 06:01:50 +0000 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <52EDD11A.5030606@mcc.id.au> References: <52EDD11A.5030606@mcc.id.au> Message-ID: <3630DA86-381D-4907-A93F-080EED3A6C02@adobe.com> > On Feb 1, 2014, at 9:03 PM, "Cameron McCormack" <cam at mcc.id.au> wrote: > > Currently, HTML defines Document.title on SVG documents to defer to whatever the SVG specification defines for SVGDocument.title. The SVGDocument interface has gone away, so this will need to be updated. From some basic testing, it looks like SVG needs the same behaviour as HTML -- first <title> element in the document, plus the white space collapsing behaviour. Could you be more specific about that? It is not just the first title element in the document, but the first direct child of the element root. A title nested in a group or graphical element has a different meaning and shall not be used as title. If there is a nested title element but no direct title child of the SVG root, then the document has no title. This distinction is important for accessibility. > > Do you want to just handle that all in HTML? I'm not sure there's much value to duplicating either the searching for the title element or the white space collapsing behaviour in SVG itself. From cam at mcc.id.au Sat Feb 1 22:04:29 2014 From: cam at mcc.id.au (Cameron McCormack) Date: Sat, 01 Feb 2014 22:04:29 -0800 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <3630DA86-381D-4907-A93F-080EED3A6C02@adobe.com> References: <52EDD11A.5030606@mcc.id.au> <3630DA86-381D-4907-A93F-080EED3A6C02@adobe.com> Message-ID: <52EDDFED.3000307@mcc.id.au> On 1/02/2014 10:01 pm, Dirk Schulze wrote: > Could you be more specific about that? It is not just the first title > element in the document, but the first direct child of the element > root. That is what the spec says but that is not what implementations do. > A title nested in a group or graphical element has a different > meaning and shall not be used as title. If there is a nested title > element but no direct title child of the SVG root, then the document > has no title. This distinction is important for accessibility. Sure. I'd be happy with keeping the special SVG behaviour here too. Ian, if you still would prefer a hook in the SVG spec for you to refer to, rather than including this behaviour -- first <title> child of the document element -- then I can define for example "SVG title element" that represents that element. From cam at mcc.id.au Sat Feb 1 22:22:25 2014 From: cam at mcc.id.au (Cameron McCormack) Date: Sat, 01 Feb 2014 22:22:25 -0800 Subject: [whatwg] Should onfoo event handler properties be on Element or HTMLElement? In-Reply-To: <52E04FB8.5040604@mit.edu> References: <CAMQvoC=zuWHUA_Ftn4BzhBzXFc0ud4AK4pRofrL6hGFfsD3Y6Q@mail.gmail.com> <52544D14.8030905@mit.edu> <op.w93dgzf5dhsuf5@gnorps> <52E04FB8.5040604@mit.edu> Message-ID: <52EDE421.8050707@mcc.id.au> On 22/01/2014 3:09 pm, Boris Zbarsky wrote: > Or neither, if desired. In Gecko we don't expose the SVG* properties in > IDL at all... We decided against requesting adding an onzoom attribute to GlobalEventHandlers to avoid any complications with whatever solution comes out of the CSSWG who are looking into new zoom related functionality (which possibly could come out with an event named "zoom", which then might be incompatible with SVGZoom). From annevk at annevk.nl Sun Feb 2 05:09:45 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Sun, 2 Feb 2014 13:09:45 +0000 Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <52ED9C15.10903@mcc.id.au> References: <52ED9C15.10903@mcc.id.au> Message-ID: <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> On Sun, Feb 2, 2014 at 1:15 AM, Cameron McCormack <cam at mcc.id.au> wrote: > Document.activeElement is currently defined to return the <body> element if > there is not element with focus, or null if there's no <body> element. I > think it needs to return the root element when the document isn't an HTML > document (like an SVG document). You mean when there's no <body> element? -- http://annevankesteren.nl/ From jonas at sicking.cc Sun Feb 2 14:37:39 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Sun, 2 Feb 2014 14:37:39 -0800 Subject: [whatwg] IE10 inconsistency with Blob / createObjectURL In-Reply-To: <CAPJwq3X7vuxmF6DQzf13Mgxwnw6WKKQ+FifQ2_onX0iewBixdw@mail.gmail.com> References: <CAPJwq3X7vuxmF6DQzf13Mgxwnw6WKKQ+FifQ2_onX0iewBixdw@mail.gmail.com> Message-ID: <CA+c2ei9GDxC=-WibZ0QvxZ0zjtGLxtdCwH1k47UFb4+NDq=vgw@mail.gmail.com> Yup, this seems like a bug in IE. Microsoft doesn't read this list though, so I suggest contacting them directly. You might also want to file a bug against the File spec to get the spec to be even more explicit about the requirements here. https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG / Jonas On Fri, Jan 31, 2014 at 6:48 PM, K. Gadd <kg at luminance.org> wrote: > Apologies if this has come up on the list before: > > IE10 appears to have shipped implementations of the Blob constructor along > with createObjectURL. While they work, there appears to be a significant > deviation from the spec behavior (at the very least, Firefox and Chrome > implement these APIs as I'd expect). > > When a Blob gets GCed in IE10, it appears to intentionally destroy the > object URL associated with it, instead of waiting for you to revoke the > object URL. When this happens it spits out a vague console message: > > HTML7007: One or more blob URLs were revoked by closing the blob for which > they were created. These URLs will no longer resolve as the data backing > the URL has been freed. > > This is confusing because the API doesn't even have a way to 'close' blobs; > all that is necessary to trigger this is to let a Blob get collected by > going out of scope. > > From reading the spec I don't see any language that suggests this behavior > is allowed or expected. I can try to work around it by retaining all the > blobs but it seems unnecessary... > > -kg From cam at mcc.id.au Sun Feb 2 19:34:24 2014 From: cam at mcc.id.au (Cameron McCormack) Date: Mon, 03 Feb 2014 14:34:24 +1100 Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> References: <52ED9C15.10903@mcc.id.au> <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> Message-ID: <52EF0E40.1080006@mcc.id.au> Cameron McCormack wrote: >> Document.activeElement is currently defined to return the <body> >> element if there is no element with focus, or null if there's no >> <body> element. I think it needs to return the root element when >> the document isn't an HTML document (like an SVG document). Anne van Kesteren wrote: > You mean when there's no <body> element? When the document isn't an HTML document and when there is no element with focus. Browsers agree on returning null in an HTML document when there is no element with focus, no <body> element, but still a document element. From mike at w3.org Mon Feb 3 02:14:26 2014 From: mike at w3.org (Michael[tm] Smith) Date: Mon, 3 Feb 2014 19:14:26 +0900 Subject: [whatwg] inputmode feedback In-Reply-To: <alpine.DEB.2.00.1401220032560.26647@ps20323.dreamhostps.com> References: <83D6DB4D-DC3B-483D-9FD9-62D182D20F1A@apple.com> <alpine.DEB.2.00.1309170032060.12199@ps20323.dreamhostps.com> <CAAEV3pnU8aC7vFua6x0ryqtJtH5O0sNqtvpW6c5E7bVnqdgVnQ@mail.gmail.com> <20131206092729.GA95292@sideshowbarker> <CADP2=ho0di2Pu-mVveZ+iubT9Ekns+L+64_n+oygUK4wX7c33Q@mail.gmail.com> <20131206133045.GD95292@sideshowbarker> <B090F654-6B1D-46E7-AA63-B94DB6CCEA8C@apple.com> <CADP2=hqJR_zg5z=24a3qigicKWThkF4HJ-ayEz3xgg-Lh9p-gw@mail.gmail.com> <20131216093615.GI32206@sideshowbarker> <alpine.DEB.2.00.1401220032560.26647@ps20323.dreamhostps.com> Message-ID: <20140203101426.GE35206@sideshowbarker> Ian Hickson <ian at hixie.ch>, 2014-01-22 00:54 +0000: > The idea of the inputmode="" attribute is that it gives the mode that is > most likely to be needed by the user when providing input. There's various > modes that seem to make sense: > > - inserting raw latin-script characters, like passwords, product codes > > - inserting human-readable latin-script short-form text, like search > queries > > - inserting human-readable latin-script human names > > - inserting human-readable latin-script long-form text, like blog posts > > - inserting numeric data, like credit card numbers > > - inserting text in other scripts, of which I know nothing > > - inserting human-readable latin-script text within long-form text in > other scripts > > You don't use the same kind of keyboard for inserting raw latin-script > characters as for inserting Japanese long-form prose, so it makes sense to > me that they'd use different input modes. > > Why is this wrong? I personally think it's not wrong. Well, mostly not wrong, at least (see below for what I think is one specific, fixable problem.) But I believe one objection that others have made to the current set of modes is that for Latin input it provides values that conflate typing-aids hints with the script hint, while for Japanese input, it does not. That means there's at least one possibly-useful mode that inputmode currently does make expressible: a "name" mode for kana input (to correspond to the latin-name mode). What I mean is, what value would an author choose if they wanted to indicate a mode for inserting human-readable kana-input human names? It's true there's no capitalization in Japanese names (as there is with Latin names), so if all that the -name value indicated was namecase autocapitalization, we wouldn't need a kana-name value. But a UA could use the latin-name mode for more than just turning on namecase autocapitalization. For example, the spec notes that the mode could trigger "text prediction from the user's contact list". So what would an author do if they if they wanted a mode that signals both kana input and "text prediction from the user's contact list"? Asking that question makes me realize that we probably don't actually want a "-name" mode for the contact-list case anyway -- because a Japanese user is likely to have a contact list that contains names both in Kanji and in Latin characters. So if we really want to provide "text prediction from the user's contact list", I think we'd probably want to just add an script-less inputmode=contact value for that. Also, there are things other than human names for which namecase (aka titlecase) is useful: For example, a field where the user is expected to type in a book title or movie title. For those kinds of fields, you clearly wouldn't want "text prediction from the user's contact list" turned on also. Instead you'd just want it to be inputmode=titlecase. Anyway, I think the root problem might be that we have inputmode=latin-name to begin with. So I'd suggest either dropping it entirely, or replacing it with the two new values inputmode=titlecase and inputmode=contact. And as far as using inputmode for specifying typing aids instead of just script, I don't what other kinds of typing aids (other than the contact case) would be relevant for Japanese input. The main typing aids the spec mentions are autocapitalization, autocorrect, and text prediction. Among those, capitalization isn't relevant for Japanese input at all. And as far as autocorrect, in my experience at least, autocorrect isn't a feature that's commonly used anywhere with IMEs for Japanese input, so it's not relevant. And as far as text prediction, in Japanese IMEs text prediction is always turned on anyway, and I can't think of cases where a user would really care to have it turned off (or be bothered by having it on). Come to think of it, in soft keyboards on smartphones for Latin input too, text prediction is always on anyway. So maybe these days there's not much of a real need to provide a hint for a "text prediction on" typing aid -- because "text prediction on" is the default anyway. Maybe instead there's now more of a need for a "text prediction off" typing aid, I dunno. > On Mon, 16 Dec 2013, Michael[tm] Smith wrote: > > > > As I commented in bug 23961, the value of the inputmode attribute was > > originally specified as taking a list of tokens, where one token is > > optionally the name of a script like "latin" and the rest of the tokens > > were optional modifiers. > > > > So you could imagine a value like inputmode="latin titlecase > > prediction". > > > > I'm not saying I think the use cases actually merit changing the > > inputmode microsyntax to be a list of tokens like that. But it might be > > preferable to introducing yet more attributes. > > We originally had this in Wbe Forms 2.0, but it is far more complex than > necessary, IMHO. Authors don't need that level of control in the vast > majority of cases. Yeah, agreed. After thinking about it, it seems to me that we don't really have a need for any new combinations. If we were to add anything new for the use cases that have come up, I think it would just be a inputmode=contact value and maybe an inputmode=titlecase value (which would just imply Latin input, since it'd only be relevant to Latin). And drop inputmode=latin-name. --Mike -- Michael[tm] Smith http://people.w3.org/mike From annevk at annevk.nl Mon Feb 3 02:29:42 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Mon, 3 Feb 2014 10:29:42 +0000 Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <52EF0E40.1080006@mcc.id.au> References: <52ED9C15.10903@mcc.id.au> <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> <52EF0E40.1080006@mcc.id.au> Message-ID: <CADnb78jwtuKM+W3=+Cgg--J0_3XWN-9QNxO2Do-DfKNS0eAbcA@mail.gmail.com> On Mon, Feb 3, 2014 at 3:34 AM, Cameron McCormack <cam at mcc.id.au> wrote: > When the document isn't an HTML document and when there is no element with > focus. Browsers agree on returning null in an HTML document when there is > no element with focus, no <body> element, but still a document element. So how does that work for text/xml? Do you dispatch on namespace of the root element? If the root element is html in the HTML namespace, you have that behavior, and otherwise you return the root element itself? At least thus far we have cared a great deal about not introducing more differences between HTML and XHTML than necessary. I could see us caring less about it now though. -- http://annevankesteren.nl/ From bzbarsky at MIT.EDU Mon Feb 3 04:36:37 2014 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Mon, 03 Feb 2014 07:36:37 -0500 Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <CADnb78jwtuKM+W3=+Cgg--J0_3XWN-9QNxO2Do-DfKNS0eAbcA@mail.gmail.com> References: <52ED9C15.10903@mcc.id.au> <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> <52EF0E40.1080006@mcc.id.au> <CADnb78jwtuKM+W3=+Cgg--J0_3XWN-9QNxO2Do-DfKNS0eAbcA@mail.gmail.com> Message-ID: <52EF8D55.3060705@mit.edu> On 2/3/14 5:29 AM, Anne van Kesteren wrote: > So how does that work for text/xml? Do you dispatch on namespace of > the root element? What Gecko does is that if the document is an HTMLDocument (so is text/html or application/xhtml+xml) and hence has a .body property we use that. Otherwise we use .documentElement. Of course the spec has no concept of HTMLDocument and has a .body on all documents... -Boris From simonp at opera.com Mon Feb 3 05:27:53 2014 From: simonp at opera.com (Simon Pieters) Date: Mon, 03 Feb 2014 14:27:53 +0100 Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <CADnb78jwtuKM+W3=+Cgg--J0_3XWN-9QNxO2Do-DfKNS0eAbcA@mail.gmail.com> References: <52ED9C15.10903@mcc.id.au> <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> <52EF0E40.1080006@mcc.id.au> <CADnb78jwtuKM+W3=+Cgg--J0_3XWN-9QNxO2Do-DfKNS0eAbcA@mail.gmail.com> Message-ID: <op.xapjoreiidj3kv@simons-mbp> On Mon, 03 Feb 2014 11:29:42 +0100, Anne van Kesteren <annevk at annevk.nl> wrote: > On Mon, Feb 3, 2014 at 3:34 AM, Cameron McCormack <cam at mcc.id.au> wrote: >> When the document isn't an HTML document and when there is no element >> with >> focus. Browsers agree on returning null in an HTML document when there >> is >> no element with focus, no <body> element, but still a document element. [...] > If the root element is html in the HTML namespace, > you have that behavior, and otherwise you return the root element > itself? That sounds good to me. -- Simon Pieters Opera Software From ben at benv.ca Mon Feb 3 11:23:33 2014 From: ben at benv.ca (Ben Vinegar) Date: Mon, 3 Feb 2014 11:23:33 -0800 Subject: [whatwg] Feedback on seamless iframe attribute Message-ID: <CAA-7dEo9ZyhJABdE1O4H5E2d=xpxwWs=mm=uNn_H3oijOPZpCQ@mail.gmail.com> Hi there, I wanted to offer some feedback on the seamless iframe attribute. [1] Some context: I?m a software engineer at Disqus, an embedded discussion platform that uses iframes heavily. I?m also the co-author of Third-party JavaScript, and I?ve given talks about seamless and how to emulate its behaviour in browsers that don?t support it. Ultimately, seamless doesn?t affect Disqus, because it only applies to iframes that share the same origin as the browsing context. Which is good, because we don?t want to use the seamless attribute anyways ? it would let publishers manipulate the styles of our application, which besides being potentially dangerous, is not something we want them doing. But while we?re not interested in the style component of the seamless attribute, we ? and probably all developers that hack on iframes ? are interested in the resizing behaviour it introduces. Right now we deploy fairly complex code, both inside the iframed document, and on the parent document, to resize the iframe element when the iframed content changes size [2]. Every iframed application with dynamically-sized content does the same. To me, it?s crazy that it?s 2013 and there?s still no native way to have the browser automatically resize an iframe. And yet we have seamless. But it not only resizes: it adds all this other bundled behaviour, and strictly serves a fringe use case where somebody is distributing iframes on the same origin. My suggestion is to split seamless into its three major parts: style inheritance, iframe resizing, and browsing context. Let the iframed _document_ declare whether it opts into style inheritance and/or parent browsing context (the latter can already be achieved by <base target=?_parent?>). Let the iframe _element_ declare whether it should auto-resize (e.g. <iframe resizable>). This way each context permits the other party to have additional control over its document (e.g. the parent allows the iframe to be resized according to the iframed document?s content, the iframed document allows the parent to apply styles to it). Since the size of the iframe element could leak session information, perhaps the iframed document additionally specifies a header for permitting the behaviour (like ResourceTiming or CORS). This way, everybody wins. Embedded developers will finally have a method for having their iframes automatically resize. They?ll also be able to opt-in their documents to inherit styles from the parent document ? even if they?re cross-origin. In other words, this will greatly expand the scope of possible applications beyond what seamless was capable of. Hopefully this makes sense. I've I've missed something, please let me know. Thanks, - Ben [1] http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#attr-iframe-seamless [2] http://benvinegar.github.io/seamless-talk/#/32 From ian at hixie.ch Mon Feb 3 11:37:16 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 3 Feb 2014 19:37:16 +0000 (UTC) Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <52ED9C15.10903@mcc.id.au> References: <52ED9C15.10903@mcc.id.au> Message-ID: <alpine.DEB.2.00.1402031931500.30855@ps20323.dreamhostps.com> On Sat, 1 Feb 2014, Cameron McCormack wrote: > > Document.activeElement is currently defined to return the <body> element > if there is not element with focus, or null if there's no <body> > element. I think it needs to return the root element when the document > isn't an HTML document (like an SVG document). I'm actually about to completely revamp how focus is defined, so that it actually matches reality way better (e.g. right now the spec completely misses that it's the viewport that's focused when "nothing" is focused, and fails to even allow scroll regions to be focused, etc), and so that it properly supports <dialog>s as a separate kind of focusable object. I have a detailed proposal here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23475#c16 I've noted your proposal above in comment 18. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From anewpage.media at gmail.com Mon Feb 3 11:38:17 2014 From: anewpage.media at gmail.com (Brian Blakely) Date: Mon, 3 Feb 2014 14:38:17 -0500 Subject: [whatwg] Comments on <dialog> In-Reply-To: <alpine.DEB.2.00.1402010026410.26647@ps20323.dreamhostps.com> References: <CAJ_xCi=dZeocSKh=okFnwVfq15PfXQUNsrtOxLQ4Y1yyM_wQdg@mail.gmail.com> <Pine.LNX.4.64.1304221922420.18848@ps20323.dreamhostps.com> <661F94F1-F67E-4AE6-87C0-AA0CAF9B57FF@apple.com> <alpine.DEB.2.00.1308270030250.28417@ps20323.dreamhostps.com> <CANMdWTtM00BSP0qFShRfRXQOa9W-0T6Km+zicxekykqWi2F7WA@mail.gmail.com> <alpine.DEB.2.00.1309261841150.12199@ps20323.dreamhostps.com> <CAJ_xCimEQKk_y1osA1Lm_v2CzkRZdD80T25Q2MubN9G0xFHTpg@mail.gmail.com> <CAO8i3idm+_jg_0-9EJ=4JsmraNHYvwk6zfEL3uTOAG=DwamZyQ@mail.gmail.com> <CAJ_xCikrFgN9jS0hqaU=scypz+i=kM8-iKyL9roZriiss7UHeQ@mail.gmail.com> <alpine.DEB.2.00.1312171758550.27766@ps20323.dreamhostps.com> <CAJGQg4HsVWBtjLYTppm=tKAeENiwvSr08CdbOyzLi57MRtkd2A@mail.gmail.com> <alpine.DEB.2.00.1312181912580.23407@ps20323.dreamhostps.com> <CAJGQg4FSDyDHsZ8gpi3KRahiPreGrXwV4c7rsXmqAuJTJxppNQ@mail.gmail.com> <CAO9Q3iKgRDqp59X5XCcAD=acE33a1M3zRBD8RrcATWYRm7kt9g@mail.gmail.com> <alpine.DEB.2.00.1402010026410.26647@ps20323.dreamhostps.com> Message-ID: <CAJGQg4GNQkGLarec32zffTA5Xgc8KRaj2y6LjO6+Mp1H5-A9dQ@mail.gmail.com> On Fri, Jan 31, 2014 at 7:31 PM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 18 Dec 2013, Brian Blakely wrote: > > On Wed, Dec 18, 2013 at 2:13 PM, Ian Hickson <ian at hixie.ch> wrote: > > > On Wed, 18 Dec 2013, Brian Blakely wrote: > > > > On Tue, Dec 17, 2013 at 3:14 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > > > > > I've added a rule to the spec that says that viewports have to be > > > > > pannable so you can see all of a dialog, but I don't know how > > > > > feasible that really is. > > > > > > > > I could see implementations using shadow <div>s to satisfy this It > > > > might be beneficial to even codify kind of element as ::modal, > > > > representing a modal layer acting as an ancestor for both the > > > > ::backdrop and <dialog>. > > > > > > Not really sure how this would work. Can you elaborate? > > > > This is what the shadow DOM would look like for modal dialogs: > > > > ::modal > > - ::backdrop > > - <dialog> > > > > ::modal is <dialog>'s ancestor, and is available when showModal is > > called. This allows authors to set CSS overflow to whichever value suits > > their use-case, and for user agents to establish overflow: auto as the > > default, making the dialog inherently pannable when it exceeds the > > viewport. > > That seem somewhat novel, from the CSS perspective. I'll have to defer to > implementors as to how feasible something like that is. So far, the > feedback doesn't seem positive: > ::modal is essentially a named alias for ::outside ( http://www.w3.org/TR/css3-content/#wrapping), which, sadly, has not been implemented anywhere and hasn't seen public movement in quite a long while. From ian at hixie.ch Mon Feb 3 11:42:33 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 3 Feb 2014 19:42:33 +0000 (UTC) Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <op.xapjoreiidj3kv@simons-mbp> References: <52ED9C15.10903@mcc.id.au> <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> <52EF0E40.1080006@mcc.id.au> <CADnb78jwtuKM+W3=+Cgg--J0_3XWN-9QNxO2Do-DfKNS0eAbcA@mail.gmail.com> <op.xapjoreiidj3kv@simons-mbp> Message-ID: <alpine.DEB.2.00.1402031939280.30855@ps20323.dreamhostps.com> On Mon, 3 Feb 2014, Anne van Kesteren wrote: > On Mon, Feb 3, 2014 at 3:34 AM, Cameron McCormack <cam at mcc.id.au> wrote: > > When the document isn't an HTML document and when there is no element > > with focus. Browsers agree on returning null in an HTML document when > > there is no element with focus, no <body> element, but still a > > document element. That case is obscure, though (I mean, it can only happen if you literally replace the <body> or <frameset> element with something else, like a <div>... and while I acknowledge that the Web is a wild, wild place, I doubt there are many pages that actually do that and, on top of that, depend on activeElement returning null). It seems simpler to just try to use "the body element" (as defined in the HTML spec, it's not a <body> necessarily), and if that fails, use the root if there is one or null otherwise. On Mon, 3 Feb 2014, Boris Zbarsky wrote: > > What Gecko does is that if the document is an HTMLDocument (so is > text/html or application/xhtml+xml) and hence has a .body property we > use that. Otherwise we use .documentElement. > > Of course the spec has no concept of HTMLDocument and has a .body on all > documents... Yeah, that would hurt the ability to use HTML from other namespaces (since the HTML helper stuff on the Document would be missing). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Feb 3 11:42:33 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 3 Feb 2014 19:42:33 +0000 (UTC) Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <op.xapjoreiidj3kv@simons-mbp> References: <52ED9C15.10903@mcc.id.au> <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> <52EF0E40.1080006@mcc.id.au> <CADnb78jwtuKM+W3=+Cgg--J0_3XWN-9QNxO2Do-DfKNS0eAbcA@mail.gmail.com> <op.xapjoreiidj3kv@simons-mbp> Message-ID: <alpine.DEB.2.00.1402031939280.30855@ps20323.dreamhostps.com> On Mon, 3 Feb 2014, Anne van Kesteren wrote: > On Mon, Feb 3, 2014 at 3:34 AM, Cameron McCormack <cam at mcc.id.au> wrote: > > When the document isn't an HTML document and when there is no element > > with focus. Browsers agree on returning null in an HTML document when > > there is no element with focus, no <body> element, but still a > > document element. That case is obscure, though (I mean, it can only happen if you literally replace the <body> or <frameset> element with something else, like a <div>... and while I acknowledge that the Web is a wild, wild place, I doubt there are many pages that actually do that and, on top of that, depend on activeElement returning null). It seems simpler to just try to use "the body element" (as defined in the HTML spec, it's not a <body> necessarily), and if that fails, use the root if there is one or null otherwise. On Mon, 3 Feb 2014, Boris Zbarsky wrote: > > What Gecko does is that if the document is an HTMLDocument (so is > text/html or application/xhtml+xml) and hence has a .body property we > use that. Otherwise we use .documentElement. > > Of course the spec has no concept of HTMLDocument and has a .body on all > documents... Yeah, that would hurt the ability to use HTML from other namespaces (since the HTML helper stuff on the Document would be missing). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Feb 3 11:44:28 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 3 Feb 2014 19:44:28 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: <52EDD11A.5030606@mcc.id.au> References: <52EDD11A.5030606@mcc.id.au> Message-ID: <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> On Sat, 1 Feb 2014, Cameron McCormack wrote: > > Currently, HTML defines Document.title on SVG documents to defer to > whatever the SVG specification defines for SVGDocument.title. The > SVGDocument interface has gone away, so this will need to be updated. > From some basic testing, it looks like SVG needs the same behaviour as > HTML -- first <title> element in the document, plus the white space > collapsing behaviour. > > Do you want to just handle that all in HTML? I'm not sure there's much > value to duplicating either the searching for the title element or the > white space collapsing behaviour in SVG itself. I'm all for handling it in one place. What precisely do you want the behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- "the first <svg:title> element" may come after "the first <html:title> element", and vice versa. Also consider when one or the other is "primary" but the relevant element is absent.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Feb 3 11:48:44 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 3 Feb 2014 19:48:44 +0000 (UTC) Subject: [whatwg] Comments on <dialog> In-Reply-To: <CAJGQg4GNQkGLarec32zffTA5Xgc8KRaj2y6LjO6+Mp1H5-A9dQ@mail.gmail.com> References: <CAJ_xCi=dZeocSKh=okFnwVfq15PfXQUNsrtOxLQ4Y1yyM_wQdg@mail.gmail.com> <alpine.DEB.2.00.1308270030250.28417@ps20323.dreamhostps.com> <CANMdWTtM00BSP0qFShRfRXQOa9W-0T6Km+zicxekykqWi2F7WA@mail.gmail.com> <alpine.DEB.2.00.1309261841150.12199@ps20323.dreamhostps.com> <CAJ_xCimEQKk_y1osA1Lm_v2CzkRZdD80T25Q2MubN9G0xFHTpg@mail.gmail.com> <CAO8i3idm+_jg_0-9EJ=4JsmraNHYvwk6zfEL3uTOAG=DwamZyQ@mail.gmail.com> <CAJ_xCikrFgN9jS0hqaU=scypz+i=kM8-iKyL9roZriiss7UHeQ@mail.gmail.com> <alpine.DEB.2.00.1312171758550.27766@ps20323.dreamhostps.com> <CAJGQg4HsVWBtjLYTppm=tKAeENiwvSr08CdbOyzLi57MRtkd2A@mail.gmail.com> <alpine.DEB.2.00.1312181912580.23407@ps20323.dreamhostps.com> <CAJGQg4FSDyDHsZ8gpi3KRahiPreGrXwV4c7rsXmqAuJTJxppNQ@mail.gmail.com> <CAO9Q3iKgRDqp59X5XCcAD=acE33a1M3zRBD8RrcATWYRm7kt9g@mail.gmail.com> <alpine.DEB.2.00.1402010026410.26647@ps20323.dreamhostps.com> <CAJGQg4GNQkGLarec32zffTA5Xgc8KRaj2y6LjO6+Mp1H5-A9dQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1402031946150.30855@ps20323.dreamhostps.com> On Mon, 3 Feb 2014, Brian Blakely wrote: > On Fri, Jan 31, 2014 at 7:31 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 18 Dec 2013, Brian Blakely wrote: > > > > > > This is what the shadow DOM would look like for modal dialogs: > > > > > > ::modal > > > - ::backdrop > > > - <dialog> > > > > > > ::modal is <dialog>'s ancestor, and is available when showModal is > > > called. This allows authors to set CSS overflow to whichever value > > > suits their use-case, and for user agents to establish overflow: > > > auto as the default, making the dialog inherently pannable when it > > > exceeds the viewport. > > > > That seem somewhat novel, from the CSS perspective. I'll have to defer > > to implementors as to how feasible something like that is. [...] > > ::modal is essentially a named alias for ::outside ( > http://www.w3.org/TR/css3-content/#wrapping), which, sadly, has not been > implemented anywhere and hasn't seen public movement in quite a long > while. Yeah. ::outside is pretty novel also, from a CSS perspective. That might well be why it hasn't gone anywhere since I originally specced it in early 2002/2003. I think it'd be great for it to be implemented, but we're more likely to get there by pushing ::outside than trying to push a special case version of it, I think. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jonas at sicking.cc Mon Feb 3 11:53:14 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Mon, 3 Feb 2014 11:53:14 -0800 Subject: [whatwg] onclose events for MessagePort In-Reply-To: <alpine.DEB.2.00.1401301806420.26647@ps20323.dreamhostps.com> References: <CANTur_5wOh09o5M65uzaMjbOzeCVWw5862cq8s-5V-jk=NJKpA@mail.gmail.com> <524AFFD0.9040400@helsinki.fi> <CAArhhist8=3Dq_AvpLDK_OD6_KmuNaPg8zTzdv3poGvcapaUQw@mail.gmail.com> <1410130868.1598018.1380715358709.JavaMail.zimbra@mozilla.com> <alpine.DEB.2.00.1312062200280.27766@ps20323.dreamhostps.com> <CANTur_7DNZ4yUT0v0vpkgr0puCJG+ePkk-cd+8oz_wXUhVm_Lw@mail.gmail.com> <alpine.DEB.2.00.1312111759180.27766@ps20323.dreamhostps.com> <CA+c2ei_cBi8Y3yVjf50EMFhtD5h=CYWvz+_H-SjV4VhzErZcxg@mail.gmail.com> <alpine.DEB.2.00.1312112345560.26758@ps20323.dreamhostps.com> <CA+c2ei-22s2C7JRvCc4gMXKTwLBdP8XWai38t9-6YBjpaQ8i4A@mail.gmail.com> <CA+c2ei-HRv8rQWpse41Fu4pFg1w_ZO2qbdAAF3v_rV4P=5h7FQ@mail.gmail.com> <alpine.DEB.2.00.1312132208150.27766@ps20323.dreamhostps.com> <CA+c2ei_9UU0JKNv8-_V3ae04StgmcjG-Xrcgw_LdTJ8go=Nikw@mail.gmail.com> <alpine.DEB.2.00.1401301806420.26647@ps20323.dreamhostps.com> Message-ID: <CA+c2ei_Yuywghk12GO9Rdhe=_TGrtX2d_f1_-sfuWskifoqiNQ@mail.gmail.com> On Thu, Jan 30, 2014 at 11:41 AM, Ian Hickson <ian at hixie.ch> wrote: > On Fri, 13 Dec 2013, Jonas Sicking wrote: >> On Fri, Dec 13, 2013 at 3:29 PM, Ian Hickson <ian at hixie.ch> wrote: >> > On Wed, 11 Dec 2013, Jonas Sicking wrote: >> >> No sync IPC needed. When a port is pinned, you send an async message >> >> to the process which contains the page for the "other side". When >> >> that process receives the message you check if the page is currently >> >> being displayed. >> >> >> >> If the page has been completely torn down then you send a message >> >> back saying that the page is dead and that the promise created during >> >> pinning should be rejected. >> >> >> >> If the page is sitting in the bfcache, you remove it from the bfcache >> >> and send a message back saying that the page is dead and that the >> >> promise created during pinning should be rejected. >> >> >> >> If the page is displayed, then you add a flag indicating that if the >> >> page is navigated away from, it should not go into the bfcache and >> >> that we should send a signal to reject the promise. >> >> >> >> Obviously if the process had crashed before we were able to process >> >> the event, you send a message back to reject the promise. >> >> >> >> The same thing is done when unpinning. You send a message to the >> >> other side saying that it's getting unpinned. >> > >> > This means that it's possible to get a lock, have the other side >> > navigate then go back, then have the other side receive the >> > notification for the lock. It's this that you need blocking IPC to >> > prevent. But I guess we could live with that just being possible. >> >> Indeed. The idea with bfcache is that going back/forward should be >> largely transparent to the page itself. So I think it's fine that it's >> transparent also to the page that's talking to it in this instance. >> >> Kicking the page out of bfcache isn't a goal in and of itself. The goal >> is to prevent other pages from waiting unduly long for a message. > > This basically boils down to being able to flip a switch on a MessagePort > saying that the port should not be GC'ed and should prevent its owner's > pages from being bfcached, right? I'm still very uncomfortable with this > idea of preventing either of these. Having a way to prevent GC on objects > that would otherwise get GC'ed seems like it would result in leaks, and > preventing bfcache seems like it would defeat the entire bfcache idea > (consider what happens if some ad networks start using shared workers to > make obtaining and showing ads more efficient, and they communicate with > the host pages with ports that they block bfcache on -- suddently large > parts of the Web would have bfcache defeated). I agree that being able to prevent an object from getting GCed isn't great, however any solution in this space is going to require the UA to retain a bit more memory. The reason that we need to retain the MessagePort object in the solutions discussed so far is that we've tried to fire the event on the MessagePort object itself. If we instead fired an event on the global indicating "the other side has gone away", then a MessagePort doesn't need to be retained. However such a solution requires a different way to identify which communication channel was severed. We could allow naming ports and then the name of the port would be included in the "lost connection to an other side". Of course, that requires keeping that name in memory which is arguably as leaky. Or we could come up with numeric port identifiers, in which case less memory is "leaked". Another way to reduce leaks would be to not have explicit API for locking and releasing a port. Instead you could indicate with a sent message that a response is expected, and then allow the other side to explicitly respond to the message, at which case the port would be automatically released. This is in theory just as leaky, however the syntax might encourage fewer leaks in practice. Another thing that could help is to expose a property somewhere which contains a list of the currently un-GCable ports. This way a page could on a regular basis inspect if it has leaked any ports and clean them up. I'm happy to explore any of these options. Ultimately though trying to aim for "no leaks" isn't really a well defined goal. The bfcache issue is solvable as discussed. >> We could allow bfcaching here by introducing the discussed separate >> features which allow the page to signal that it's fine with being >> bfcached even though the error was signaled. That way if the page is >> revived from bfcache it can send a message on the channel saying "I'm >> back now" at which point they can resume communicating. > > How would this work when a page has several libraries (e.g. ads, Facebook > like button, Twitter tweet button), each talking to their shared worker, > and each with different opinions about whether or not they can handle a > bfcache situation? As soon as any of them can't deal with bfcache the page won't be bfcached. I.e. you could add an API which indicates "I'm currently talking through this MessagePort object. But still let me go into bfcache." If all MessagePorts are accounted for, the page can go into bfcache. If a single port is not accounted for, the page does not get bfcached. > What the spec has now (MessagePort.onerror) only helps for the limited > case of a process getting killed by the system; it doesn't help for any of > the features of the Web platform like navigation, Worker.terminate(), etc. > > Maybe the right thing here is for you (browser vendors) to experiment with > different approaches to this, and for me to just spec whatever comes out > of that. I'm happy to experiment. In the meantime I would ask that MessagePort.onerror is removed as I don't think any browser vendor has expressed a desire to implement. / Jonas From ian at hixie.ch Mon Feb 3 12:29:59 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 3 Feb 2014 20:29:59 +0000 (UTC) Subject: [whatwg] onclose events for MessagePort In-Reply-To: <CA+c2ei_Yuywghk12GO9Rdhe=_TGrtX2d_f1_-sfuWskifoqiNQ@mail.gmail.com> References: <CANTur_5wOh09o5M65uzaMjbOzeCVWw5862cq8s-5V-jk=NJKpA@mail.gmail.com> <524AFFD0.9040400@helsinki.fi> <CAArhhist8=3Dq_AvpLDK_OD6_KmuNaPg8zTzdv3poGvcapaUQw@mail.gmail.com> <1410130868.1598018.1380715358709.JavaMail.zimbra@mozilla.com> <alpine.DEB.2.00.1312062200280.27766@ps20323.dreamhostps.com> <CANTur_7DNZ4yUT0v0vpkgr0puCJG+ePkk-cd+8oz_wXUhVm_Lw@mail.gmail.com> <alpine.DEB.2.00.1312111759180.27766@ps20323.dreamhostps.com> <CA+c2ei_cBi8Y3yVjf50EMFhtD5h=CYWvz+_H-SjV4VhzErZcxg@mail.gmail.com> <alpine.DEB.2.00.1312112345560.26758@ps20323.dreamhostps.com> <CA+c2ei-22s2C7JRvCc4gMXKTwLBdP8XWai38t9-6YBjpaQ8i4A@mail.gmail.com> <CA+c2ei-HRv8rQWpse41Fu4pFg1w_ZO2qbdAAF3v_rV4P=5h7FQ@mail.gmail.com> <alpine.DEB.2.00.1312132208150.27766@ps20323.dreamhostps.com> <CA+c2ei_9UU0JKNv8-_V3ae04StgmcjG-Xrcgw_LdTJ8go=Nikw@mail.gmail.com> <alpine.DEB.2.00.1401301806420.26647@ps20323.dreamhostps.com> <CA+c2ei_Yuywghk12GO9Rdhe=_TGrtX2d_f1_-sfuWskifoqiNQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1402032023590.30855@ps20323.dreamhostps.com> On Mon, 3 Feb 2014, Jonas Sicking wrote: > > I agree that being able to prevent an object from getting GCed isn't > great, however any solution in this space is going to require the UA to > retain a bit more memory. The reason that we need to retain the > MessagePort object in the solutions discussed so far is that we've tried > to fire the event on the MessagePort object itself. If we instead fired > an event on the global indicating "the other side has gone away", then a > MessagePort doesn't need to be retained. > > However such a solution requires a different way to identify which > communication channel was severed. We could allow naming ports and then > the name of the port would be included in the "lost connection to an > other side". Of course, that requires keeping that name in memory which > is arguably as leaky. Or we could come up with numeric port identifiers, > in which case less memory is "leaked". I think this would just result in authors keeping track of the ports in an index, which would prevent them from being GC'ed, which defeats the point. > The bfcache issue is solvable as discussed. > [...] > As soon as any of them can't deal with bfcache the page won't be > bfcached. I don't think "solvable" is the same as "design an API that basically guarantees that within a decade most of the Web won't be bfcached". > I'm happy to experiment. In the meantime I would ask that > MessagePort.onerror is removed as I don't think any browser vendor has > expressed a desire to implement. Done. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Feb 3 15:39:13 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 3 Feb 2014 23:39:13 +0000 (UTC) Subject: [whatwg] inputmode feedback In-Reply-To: <20140203101426.GE35206@sideshowbarker> References: <83D6DB4D-DC3B-483D-9FD9-62D182D20F1A@apple.com> <alpine.DEB.2.00.1309170032060.12199@ps20323.dreamhostps.com> <CAAEV3pnU8aC7vFua6x0ryqtJtH5O0sNqtvpW6c5E7bVnqdgVnQ@mail.gmail.com> <20131206092729.GA95292@sideshowbarker> <CADP2=ho0di2Pu-mVveZ+iubT9Ekns+L+64_n+oygUK4wX7c33Q@mail.gmail.com> <20131206133045.GD95292@sideshowbarker> <B090F654-6B1D-46E7-AA63-B94DB6CCEA8C@apple.com> <CADP2=hqJR_zg5z=24a3qigicKWThkF4HJ-ayEz3xgg-Lh9p-gw@mail.gmail.com> <20131216093615.GI32206@sideshowbarker> <alpine.DEB.2.00.1401220032560.26647@ps20323.dreamhostps.com> <20140203101426.GE35206@sideshowbarker> Message-ID: <alpine.DEB.2.00.1402032325460.26647@ps20323.dreamhostps.com> On Mon, 3 Feb 2014, Michael[tm] Smith wrote: > Ian Hickson <ian at hixie.ch>, 2014-01-22 00:54 +0000: > > > > The idea of the inputmode="" attribute is that it gives the mode that > > is most likely to be needed by the user when providing input. There's > > various modes that seem to make sense: > > > > - inserting raw latin-script characters, like passwords, product > > codes > > > > - inserting human-readable latin-script short-form text, like search > > queries > > > > - inserting human-readable latin-script human names > > > > - inserting human-readable latin-script long-form text, like blog > > posts > > > > - inserting numeric data, like credit card numbers > > > > - inserting text in other scripts, of which I know nothing > > > > - inserting human-readable latin-script text within long-form text in > > other scripts > > > > You don't use the same kind of keyboard for inserting raw latin-script > > characters as for inserting Japanese long-form prose, so it makes > > sense to me that they'd use different input modes. > > > > Why is this wrong? > > I personally think it's not wrong. Well, mostly not wrong, at least (see > below for what I think is one specific, fixable problem.) But I believe > one objection that others have made to the current set of modes is that > for Latin input it provides values that conflate typing-aids hints with > the script hint, while for Japanese input, it does not. Well, nobody has suggested that there are any typing aid hints applicable to Japanese input yet. The current list for Japanese (and all non-Latin- script languages) are just the list of input modes people told me were needed (since nobody has asked for anything for anything but Japanese and Latin-script languages, there's nothing for those). > That means there's at least one possibly-useful mode that inputmode > currently does make expressible: a "name" mode for kana input (to > correspond to the latin-name mode). Added. > What I mean is, what value would an author choose if they wanted to > indicate a mode for inserting human-readable kana-input human names? As of now, "kana-name". > Asking that question makes me realize that we probably don't actually > want a "-name" mode for the contact-list case anyway -- because a > Japanese user is likely to have a contact list that contains names both > in Kanji and in Latin characters. So if we really want to provide "text > prediction from the user's contact list", I think we'd probably want to > just add an script-less inputmode=contact value for that. If there was going to be a "keyboard" that consisted primarily of a contact list, I'd agree. But the keyboard will be a keyboard, and it'll autocomplete from a contact list. And thus that keyboard needs a default mode to be in. If all my friends have Latin-script names, it is inconvenient if the keyboard starts with a Russian keyboard. I presume, based on what you suggested above, that a Japanese user would find it more helpful if their keyboard started in a mode for "kana or romaji input, typically hiragana input". > Also, there are things other than human names for which namecase (aka > titlecase) is useful: For example, a field where the user is expected to > type in a book title or movie title. For those kinds of fields, you > clearly wouldn't want "text prediction from the user's contact list" > turned on also. Instead you'd just want it to be inputmode=titlecase. If users actually want auto-title-casing, then yes, we could introduce a "latin-title-case" mode, or something like that. Do they? I haven't heard of a request for this so far. > Anyway, I think the root problem might be that we have > inputmode=latin-name to begin with. I don't understand why it's a problem. > So I'd suggest either dropping it entirely, or replacing it with the two > new values inputmode=titlecase and inputmode=contact. That wouldn't give the UA the information the UA needs to pick the right keyboard. > And as far as using inputmode for specifying typing aids instead of just > script, I don't what other kinds of typing aids (other than the contact > case) would be relevant for Japanese input. The main typing aids the > spec mentions are autocapitalization, autocorrect, and text prediction. > Among those, capitalization isn't relevant for Japanese input at all. > And as far as autocorrect, in my experience at least, autocorrect isn't > a feature that's commonly used anywhere with IMEs for Japanese input, so > it's not relevant. And as far as text prediction, in Japanese IMEs text > prediction is always turned on anyway, and I can't think of cases where > a user would really care to have it turned off (or be bothered by having > it on). Right, each script has different needs. That's why these are not orthogonal concerns; they're input modalities. I don't know anything about what input modalities are needed outside of Latin script keyboards, so I rely on people reporting what is missing so that I can add it. > Come to think of it, in soft keyboards on smartphones for Latin input too, > text prediction is always on anyway. Not always. For example, you wouldn't want to have it on in a password field or URL field. > So maybe these days there's not much of a real need to provide a hint > for a "text prediction on" typing aid -- because "text prediction on" is > the default anyway. Maybe instead there's now more of a need for a "text > prediction off" typing aid, I dunno. The spec doesn't have a default mode and an "on" mode (or "off" mode), it just has various different modes, some with and some without certain features (or rather, hints as to whether those features should be there or not by default). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cam at mcc.id.au Mon Feb 3 16:25:09 2014 From: cam at mcc.id.au (Cameron McCormack) Date: Tue, 04 Feb 2014 11:25:09 +1100 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> Message-ID: <52F03365.5050004@mcc.id.au> Ian Hickson wrote: > I'm all for handling it in one place. What precisely do you want the > behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- "the first > <svg:title> element" may come after "the first<html:title> element", and > vice versa. Also consider when one or the other is "primary" but the > relevant element is absent.) OK, how about: if the document element is an <html:html>, we choose the first <html:title> in document order; if the document element is an <svg:svg>, we choose the first child <svg:title> of the document element; otherwise, null. This still is going to produce "incorrect" results for things like: <!DOCTYPE html> <svg> <foreignObject> <title>blah

From cam at mcc.id.au Sat Feb 1 17:15:01 2014 From: cam at mcc.id.au (Cameron McCormack) Date: Sat, 01 Feb 2014 17:15:01 -0800 Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus Message-ID: <52ED9C15.10903@mcc.id.au> Document.activeElement is currently defined to return the element if there is not element with focus, or null if there's no element. I think it needs to return the root element when the document isn't an HTML document (like an SVG document). From cam at mcc.id.au Sat Feb 1 21:01:14 2014 From: cam at mcc.id.au (Cameron McCormack) Date: Sat, 01 Feb 2014 21:01:14 -0800 Subject: [whatwg] Document.title for SVG documents Message-ID: <52EDD11A.5030606@mcc.id.au> Currently, HTML defines Document.title on SVG documents to defer to whatever the SVG specification defines for SVGDocument.title. The SVGDocument interface has gone away, so this will need to be updated. From some basic testing, it looks like SVG needs the same behaviour as HTML -- first element in the document, plus the white space collapsing behaviour. Do you want to just handle that all in HTML? I'm not sure there's much value to duplicating either the searching for the title element or the white space collapsing behaviour in SVG itself. From cam at mcc.id.au Sat Feb 1 21:28:48 2014 From: cam at mcc.id.au (Cameron McCormack) Date: Sat, 01 Feb 2014 21:28:48 -0800 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <52EDD11A.5030606@mcc.id.au> References: <52EDD11A.5030606@mcc.id.au> Message-ID: <52EDD790.7080303@mcc.id.au> On 1/02/2014 9:01 pm, Cameron McCormack wrote: > Do you want to just handle that all in HTML? I'm not sure there's much > value to duplicating either the searching for the title element or the > white space collapsing behaviour in SVG itself. Oh, and for the setter, it looks like implementations don't do anything when assigning to document.title in SVG documents. (Chrome does something funny where it remembers what you assign to document.title, but it doesn't affect what's in the <title> element.) I don't have a strong opinion on whether we should make the setter do something useful or nothing at all. If we do, any newly created <title> element should be appended to the document element. From dschulze at adobe.com Sat Feb 1 22:01:50 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Sun, 2 Feb 2014 06:01:50 +0000 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <52EDD11A.5030606@mcc.id.au> References: <52EDD11A.5030606@mcc.id.au> Message-ID: <3630DA86-381D-4907-A93F-080EED3A6C02@adobe.com> > On Feb 1, 2014, at 9:03 PM, "Cameron McCormack" <cam at mcc.id.au> wrote: > > Currently, HTML defines Document.title on SVG documents to defer to whatever the SVG specification defines for SVGDocument.title. The SVGDocument interface has gone away, so this will need to be updated. From some basic testing, it looks like SVG needs the same behaviour as HTML -- first <title> element in the document, plus the white space collapsing behaviour. Could you be more specific about that? It is not just the first title element in the document, but the first direct child of the element root. A title nested in a group or graphical element has a different meaning and shall not be used as title. If there is a nested title element but no direct title child of the SVG root, then the document has no title. This distinction is important for accessibility. > > Do you want to just handle that all in HTML? I'm not sure there's much value to duplicating either the searching for the title element or the white space collapsing behaviour in SVG itself. From cam at mcc.id.au Sat Feb 1 22:04:29 2014 From: cam at mcc.id.au (Cameron McCormack) Date: Sat, 01 Feb 2014 22:04:29 -0800 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <3630DA86-381D-4907-A93F-080EED3A6C02@adobe.com> References: <52EDD11A.5030606@mcc.id.au> <3630DA86-381D-4907-A93F-080EED3A6C02@adobe.com> Message-ID: <52EDDFED.3000307@mcc.id.au> On 1/02/2014 10:01 pm, Dirk Schulze wrote: > Could you be more specific about that? It is not just the first title > element in the document, but the first direct child of the element > root. That is what the spec says but that is not what implementations do. > A title nested in a group or graphical element has a different > meaning and shall not be used as title. If there is a nested title > element but no direct title child of the SVG root, then the document > has no title. This distinction is important for accessibility. Sure. I'd be happy with keeping the special SVG behaviour here too. Ian, if you still would prefer a hook in the SVG spec for you to refer to, rather than including this behaviour -- first <title> child of the document element -- then I can define for example "SVG title element" that represents that element. From cam at mcc.id.au Sat Feb 1 22:22:25 2014 From: cam at mcc.id.au (Cameron McCormack) Date: Sat, 01 Feb 2014 22:22:25 -0800 Subject: [whatwg] Should onfoo event handler properties be on Element or HTMLElement? In-Reply-To: <52E04FB8.5040604@mit.edu> References: <CAMQvoC=zuWHUA_Ftn4BzhBzXFc0ud4AK4pRofrL6hGFfsD3Y6Q@mail.gmail.com> <52544D14.8030905@mit.edu> <op.w93dgzf5dhsuf5@gnorps> <52E04FB8.5040604@mit.edu> Message-ID: <52EDE421.8050707@mcc.id.au> On 22/01/2014 3:09 pm, Boris Zbarsky wrote: > Or neither, if desired. In Gecko we don't expose the SVG* properties in > IDL at all... We decided against requesting adding an onzoom attribute to GlobalEventHandlers to avoid any complications with whatever solution comes out of the CSSWG who are looking into new zoom related functionality (which possibly could come out with an event named "zoom", which then might be incompatible with SVGZoom). From annevk at annevk.nl Sun Feb 2 05:09:45 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Sun, 2 Feb 2014 13:09:45 +0000 Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <52ED9C15.10903@mcc.id.au> References: <52ED9C15.10903@mcc.id.au> Message-ID: <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> On Sun, Feb 2, 2014 at 1:15 AM, Cameron McCormack <cam at mcc.id.au> wrote: > Document.activeElement is currently defined to return the <body> element if > there is not element with focus, or null if there's no <body> element. I > think it needs to return the root element when the document isn't an HTML > document (like an SVG document). You mean when there's no <body> element? -- http://annevankesteren.nl/ From jonas at sicking.cc Sun Feb 2 14:37:39 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Sun, 2 Feb 2014 14:37:39 -0800 Subject: [whatwg] IE10 inconsistency with Blob / createObjectURL In-Reply-To: <CAPJwq3X7vuxmF6DQzf13Mgxwnw6WKKQ+FifQ2_onX0iewBixdw@mail.gmail.com> References: <CAPJwq3X7vuxmF6DQzf13Mgxwnw6WKKQ+FifQ2_onX0iewBixdw@mail.gmail.com> Message-ID: <CA+c2ei9GDxC=-WibZ0QvxZ0zjtGLxtdCwH1k47UFb4+NDq=vgw@mail.gmail.com> Yup, this seems like a bug in IE. Microsoft doesn't read this list though, so I suggest contacting them directly. You might also want to file a bug against the File spec to get the spec to be even more explicit about the requirements here. https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WebAppsWG / Jonas On Fri, Jan 31, 2014 at 6:48 PM, K. Gadd <kg at luminance.org> wrote: > Apologies if this has come up on the list before: > > IE10 appears to have shipped implementations of the Blob constructor along > with createObjectURL. While they work, there appears to be a significant > deviation from the spec behavior (at the very least, Firefox and Chrome > implement these APIs as I'd expect). > > When a Blob gets GCed in IE10, it appears to intentionally destroy the > object URL associated with it, instead of waiting for you to revoke the > object URL. When this happens it spits out a vague console message: > > HTML7007: One or more blob URLs were revoked by closing the blob for which > they were created. These URLs will no longer resolve as the data backing > the URL has been freed. > > This is confusing because the API doesn't even have a way to 'close' blobs; > all that is necessary to trigger this is to let a Blob get collected by > going out of scope. > > From reading the spec I don't see any language that suggests this behavior > is allowed or expected. I can try to work around it by retaining all the > blobs but it seems unnecessary... > > -kg From cam at mcc.id.au Sun Feb 2 19:34:24 2014 From: cam at mcc.id.au (Cameron McCormack) Date: Mon, 03 Feb 2014 14:34:24 +1100 Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> References: <52ED9C15.10903@mcc.id.au> <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> Message-ID: <52EF0E40.1080006@mcc.id.au> Cameron McCormack wrote: >> Document.activeElement is currently defined to return the <body> >> element if there is no element with focus, or null if there's no >> <body> element. I think it needs to return the root element when >> the document isn't an HTML document (like an SVG document). Anne van Kesteren wrote: > You mean when there's no <body> element? When the document isn't an HTML document and when there is no element with focus. Browsers agree on returning null in an HTML document when there is no element with focus, no <body> element, but still a document element. From mike at w3.org Mon Feb 3 02:14:26 2014 From: mike at w3.org (Michael[tm] Smith) Date: Mon, 3 Feb 2014 19:14:26 +0900 Subject: [whatwg] inputmode feedback In-Reply-To: <alpine.DEB.2.00.1401220032560.26647@ps20323.dreamhostps.com> References: <83D6DB4D-DC3B-483D-9FD9-62D182D20F1A@apple.com> <alpine.DEB.2.00.1309170032060.12199@ps20323.dreamhostps.com> <CAAEV3pnU8aC7vFua6x0ryqtJtH5O0sNqtvpW6c5E7bVnqdgVnQ@mail.gmail.com> <20131206092729.GA95292@sideshowbarker> <CADP2=ho0di2Pu-mVveZ+iubT9Ekns+L+64_n+oygUK4wX7c33Q@mail.gmail.com> <20131206133045.GD95292@sideshowbarker> <B090F654-6B1D-46E7-AA63-B94DB6CCEA8C@apple.com> <CADP2=hqJR_zg5z=24a3qigicKWThkF4HJ-ayEz3xgg-Lh9p-gw@mail.gmail.com> <20131216093615.GI32206@sideshowbarker> <alpine.DEB.2.00.1401220032560.26647@ps20323.dreamhostps.com> Message-ID: <20140203101426.GE35206@sideshowbarker> Ian Hickson <ian at hixie.ch>, 2014-01-22 00:54 +0000: > The idea of the inputmode="" attribute is that it gives the mode that is > most likely to be needed by the user when providing input. There's various > modes that seem to make sense: > > - inserting raw latin-script characters, like passwords, product codes > > - inserting human-readable latin-script short-form text, like search > queries > > - inserting human-readable latin-script human names > > - inserting human-readable latin-script long-form text, like blog posts > > - inserting numeric data, like credit card numbers > > - inserting text in other scripts, of which I know nothing > > - inserting human-readable latin-script text within long-form text in > other scripts > > You don't use the same kind of keyboard for inserting raw latin-script > characters as for inserting Japanese long-form prose, so it makes sense to > me that they'd use different input modes. > > Why is this wrong? I personally think it's not wrong. Well, mostly not wrong, at least (see below for what I think is one specific, fixable problem.) But I believe one objection that others have made to the current set of modes is that for Latin input it provides values that conflate typing-aids hints with the script hint, while for Japanese input, it does not. That means there's at least one possibly-useful mode that inputmode currently does make expressible: a "name" mode for kana input (to correspond to the latin-name mode). What I mean is, what value would an author choose if they wanted to indicate a mode for inserting human-readable kana-input human names? It's true there's no capitalization in Japanese names (as there is with Latin names), so if all that the -name value indicated was namecase autocapitalization, we wouldn't need a kana-name value. But a UA could use the latin-name mode for more than just turning on namecase autocapitalization. For example, the spec notes that the mode could trigger "text prediction from the user's contact list". So what would an author do if they if they wanted a mode that signals both kana input and "text prediction from the user's contact list"? Asking that question makes me realize that we probably don't actually want a "-name" mode for the contact-list case anyway -- because a Japanese user is likely to have a contact list that contains names both in Kanji and in Latin characters. So if we really want to provide "text prediction from the user's contact list", I think we'd probably want to just add an script-less inputmode=contact value for that. Also, there are things other than human names for which namecase (aka titlecase) is useful: For example, a field where the user is expected to type in a book title or movie title. For those kinds of fields, you clearly wouldn't want "text prediction from the user's contact list" turned on also. Instead you'd just want it to be inputmode=titlecase. Anyway, I think the root problem might be that we have inputmode=latin-name to begin with. So I'd suggest either dropping it entirely, or replacing it with the two new values inputmode=titlecase and inputmode=contact. And as far as using inputmode for specifying typing aids instead of just script, I don't what other kinds of typing aids (other than the contact case) would be relevant for Japanese input. The main typing aids the spec mentions are autocapitalization, autocorrect, and text prediction. Among those, capitalization isn't relevant for Japanese input at all. And as far as autocorrect, in my experience at least, autocorrect isn't a feature that's commonly used anywhere with IMEs for Japanese input, so it's not relevant. And as far as text prediction, in Japanese IMEs text prediction is always turned on anyway, and I can't think of cases where a user would really care to have it turned off (or be bothered by having it on). Come to think of it, in soft keyboards on smartphones for Latin input too, text prediction is always on anyway. So maybe these days there's not much of a real need to provide a hint for a "text prediction on" typing aid -- because "text prediction on" is the default anyway. Maybe instead there's now more of a need for a "text prediction off" typing aid, I dunno. > On Mon, 16 Dec 2013, Michael[tm] Smith wrote: > > > > As I commented in bug 23961, the value of the inputmode attribute was > > originally specified as taking a list of tokens, where one token is > > optionally the name of a script like "latin" and the rest of the tokens > > were optional modifiers. > > > > So you could imagine a value like inputmode="latin titlecase > > prediction". > > > > I'm not saying I think the use cases actually merit changing the > > inputmode microsyntax to be a list of tokens like that. But it might be > > preferable to introducing yet more attributes. > > We originally had this in Wbe Forms 2.0, but it is far more complex than > necessary, IMHO. Authors don't need that level of control in the vast > majority of cases. Yeah, agreed. After thinking about it, it seems to me that we don't really have a need for any new combinations. If we were to add anything new for the use cases that have come up, I think it would just be a inputmode=contact value and maybe an inputmode=titlecase value (which would just imply Latin input, since it'd only be relevant to Latin). And drop inputmode=latin-name. --Mike -- Michael[tm] Smith http://people.w3.org/mike From annevk at annevk.nl Mon Feb 3 02:29:42 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Mon, 3 Feb 2014 10:29:42 +0000 Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <52EF0E40.1080006@mcc.id.au> References: <52ED9C15.10903@mcc.id.au> <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> <52EF0E40.1080006@mcc.id.au> Message-ID: <CADnb78jwtuKM+W3=+Cgg--J0_3XWN-9QNxO2Do-DfKNS0eAbcA@mail.gmail.com> On Mon, Feb 3, 2014 at 3:34 AM, Cameron McCormack <cam at mcc.id.au> wrote: > When the document isn't an HTML document and when there is no element with > focus. Browsers agree on returning null in an HTML document when there is > no element with focus, no <body> element, but still a document element. So how does that work for text/xml? Do you dispatch on namespace of the root element? If the root element is html in the HTML namespace, you have that behavior, and otherwise you return the root element itself? At least thus far we have cared a great deal about not introducing more differences between HTML and XHTML than necessary. I could see us caring less about it now though. -- http://annevankesteren.nl/ From bzbarsky at MIT.EDU Mon Feb 3 04:36:37 2014 From: bzbarsky at MIT.EDU (Boris Zbarsky) Date: Mon, 03 Feb 2014 07:36:37 -0500 Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <CADnb78jwtuKM+W3=+Cgg--J0_3XWN-9QNxO2Do-DfKNS0eAbcA@mail.gmail.com> References: <52ED9C15.10903@mcc.id.au> <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> <52EF0E40.1080006@mcc.id.au> <CADnb78jwtuKM+W3=+Cgg--J0_3XWN-9QNxO2Do-DfKNS0eAbcA@mail.gmail.com> Message-ID: <52EF8D55.3060705@mit.edu> On 2/3/14 5:29 AM, Anne van Kesteren wrote: > So how does that work for text/xml? Do you dispatch on namespace of > the root element? What Gecko does is that if the document is an HTMLDocument (so is text/html or application/xhtml+xml) and hence has a .body property we use that. Otherwise we use .documentElement. Of course the spec has no concept of HTMLDocument and has a .body on all documents... -Boris From simonp at opera.com Mon Feb 3 05:27:53 2014 From: simonp at opera.com (Simon Pieters) Date: Mon, 03 Feb 2014 14:27:53 +0100 Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <CADnb78jwtuKM+W3=+Cgg--J0_3XWN-9QNxO2Do-DfKNS0eAbcA@mail.gmail.com> References: <52ED9C15.10903@mcc.id.au> <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> <52EF0E40.1080006@mcc.id.au> <CADnb78jwtuKM+W3=+Cgg--J0_3XWN-9QNxO2Do-DfKNS0eAbcA@mail.gmail.com> Message-ID: <op.xapjoreiidj3kv@simons-mbp> On Mon, 03 Feb 2014 11:29:42 +0100, Anne van Kesteren <annevk at annevk.nl> wrote: > On Mon, Feb 3, 2014 at 3:34 AM, Cameron McCormack <cam at mcc.id.au> wrote: >> When the document isn't an HTML document and when there is no element >> with >> focus. Browsers agree on returning null in an HTML document when there >> is >> no element with focus, no <body> element, but still a document element. [...] > If the root element is html in the HTML namespace, > you have that behavior, and otherwise you return the root element > itself? That sounds good to me. -- Simon Pieters Opera Software From ben at benv.ca Mon Feb 3 11:23:33 2014 From: ben at benv.ca (Ben Vinegar) Date: Mon, 3 Feb 2014 11:23:33 -0800 Subject: [whatwg] Feedback on seamless iframe attribute Message-ID: <CAA-7dEo9ZyhJABdE1O4H5E2d=xpxwWs=mm=uNn_H3oijOPZpCQ@mail.gmail.com> Hi there, I wanted to offer some feedback on the seamless iframe attribute. [1] Some context: I?m a software engineer at Disqus, an embedded discussion platform that uses iframes heavily. I?m also the co-author of Third-party JavaScript, and I?ve given talks about seamless and how to emulate its behaviour in browsers that don?t support it. Ultimately, seamless doesn?t affect Disqus, because it only applies to iframes that share the same origin as the browsing context. Which is good, because we don?t want to use the seamless attribute anyways ? it would let publishers manipulate the styles of our application, which besides being potentially dangerous, is not something we want them doing. But while we?re not interested in the style component of the seamless attribute, we ? and probably all developers that hack on iframes ? are interested in the resizing behaviour it introduces. Right now we deploy fairly complex code, both inside the iframed document, and on the parent document, to resize the iframe element when the iframed content changes size [2]. Every iframed application with dynamically-sized content does the same. To me, it?s crazy that it?s 2013 and there?s still no native way to have the browser automatically resize an iframe. And yet we have seamless. But it not only resizes: it adds all this other bundled behaviour, and strictly serves a fringe use case where somebody is distributing iframes on the same origin. My suggestion is to split seamless into its three major parts: style inheritance, iframe resizing, and browsing context. Let the iframed _document_ declare whether it opts into style inheritance and/or parent browsing context (the latter can already be achieved by <base target=?_parent?>). Let the iframe _element_ declare whether it should auto-resize (e.g. <iframe resizable>). This way each context permits the other party to have additional control over its document (e.g. the parent allows the iframe to be resized according to the iframed document?s content, the iframed document allows the parent to apply styles to it). Since the size of the iframe element could leak session information, perhaps the iframed document additionally specifies a header for permitting the behaviour (like ResourceTiming or CORS). This way, everybody wins. Embedded developers will finally have a method for having their iframes automatically resize. They?ll also be able to opt-in their documents to inherit styles from the parent document ? even if they?re cross-origin. In other words, this will greatly expand the scope of possible applications beyond what seamless was capable of. Hopefully this makes sense. I've I've missed something, please let me know. Thanks, - Ben [1] http://www.w3.org/TR/2011/WD-html5-20110525/the-iframe-element.html#attr-iframe-seamless [2] http://benvinegar.github.io/seamless-talk/#/32 From ian at hixie.ch Mon Feb 3 11:37:16 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 3 Feb 2014 19:37:16 +0000 (UTC) Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <52ED9C15.10903@mcc.id.au> References: <52ED9C15.10903@mcc.id.au> Message-ID: <alpine.DEB.2.00.1402031931500.30855@ps20323.dreamhostps.com> On Sat, 1 Feb 2014, Cameron McCormack wrote: > > Document.activeElement is currently defined to return the <body> element > if there is not element with focus, or null if there's no <body> > element. I think it needs to return the root element when the document > isn't an HTML document (like an SVG document). I'm actually about to completely revamp how focus is defined, so that it actually matches reality way better (e.g. right now the spec completely misses that it's the viewport that's focused when "nothing" is focused, and fails to even allow scroll regions to be focused, etc), and so that it properly supports <dialog>s as a separate kind of focusable object. I have a detailed proposal here: https://www.w3.org/Bugs/Public/show_bug.cgi?id=23475#c16 I've noted your proposal above in comment 18. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From anewpage.media at gmail.com Mon Feb 3 11:38:17 2014 From: anewpage.media at gmail.com (Brian Blakely) Date: Mon, 3 Feb 2014 14:38:17 -0500 Subject: [whatwg] Comments on <dialog> In-Reply-To: <alpine.DEB.2.00.1402010026410.26647@ps20323.dreamhostps.com> References: <CAJ_xCi=dZeocSKh=okFnwVfq15PfXQUNsrtOxLQ4Y1yyM_wQdg@mail.gmail.com> <Pine.LNX.4.64.1304221922420.18848@ps20323.dreamhostps.com> <661F94F1-F67E-4AE6-87C0-AA0CAF9B57FF@apple.com> <alpine.DEB.2.00.1308270030250.28417@ps20323.dreamhostps.com> <CANMdWTtM00BSP0qFShRfRXQOa9W-0T6Km+zicxekykqWi2F7WA@mail.gmail.com> <alpine.DEB.2.00.1309261841150.12199@ps20323.dreamhostps.com> <CAJ_xCimEQKk_y1osA1Lm_v2CzkRZdD80T25Q2MubN9G0xFHTpg@mail.gmail.com> <CAO8i3idm+_jg_0-9EJ=4JsmraNHYvwk6zfEL3uTOAG=DwamZyQ@mail.gmail.com> <CAJ_xCikrFgN9jS0hqaU=scypz+i=kM8-iKyL9roZriiss7UHeQ@mail.gmail.com> <alpine.DEB.2.00.1312171758550.27766@ps20323.dreamhostps.com> <CAJGQg4HsVWBtjLYTppm=tKAeENiwvSr08CdbOyzLi57MRtkd2A@mail.gmail.com> <alpine.DEB.2.00.1312181912580.23407@ps20323.dreamhostps.com> <CAJGQg4FSDyDHsZ8gpi3KRahiPreGrXwV4c7rsXmqAuJTJxppNQ@mail.gmail.com> <CAO9Q3iKgRDqp59X5XCcAD=acE33a1M3zRBD8RrcATWYRm7kt9g@mail.gmail.com> <alpine.DEB.2.00.1402010026410.26647@ps20323.dreamhostps.com> Message-ID: <CAJGQg4GNQkGLarec32zffTA5Xgc8KRaj2y6LjO6+Mp1H5-A9dQ@mail.gmail.com> On Fri, Jan 31, 2014 at 7:31 PM, Ian Hickson <ian at hixie.ch> wrote: > On Wed, 18 Dec 2013, Brian Blakely wrote: > > On Wed, Dec 18, 2013 at 2:13 PM, Ian Hickson <ian at hixie.ch> wrote: > > > On Wed, 18 Dec 2013, Brian Blakely wrote: > > > > On Tue, Dec 17, 2013 at 3:14 PM, Ian Hickson <ian at hixie.ch> wrote: > > > > > > > > > > I've added a rule to the spec that says that viewports have to be > > > > > pannable so you can see all of a dialog, but I don't know how > > > > > feasible that really is. > > > > > > > > I could see implementations using shadow <div>s to satisfy this It > > > > might be beneficial to even codify kind of element as ::modal, > > > > representing a modal layer acting as an ancestor for both the > > > > ::backdrop and <dialog>. > > > > > > Not really sure how this would work. Can you elaborate? > > > > This is what the shadow DOM would look like for modal dialogs: > > > > ::modal > > - ::backdrop > > - <dialog> > > > > ::modal is <dialog>'s ancestor, and is available when showModal is > > called. This allows authors to set CSS overflow to whichever value suits > > their use-case, and for user agents to establish overflow: auto as the > > default, making the dialog inherently pannable when it exceeds the > > viewport. > > That seem somewhat novel, from the CSS perspective. I'll have to defer to > implementors as to how feasible something like that is. So far, the > feedback doesn't seem positive: > ::modal is essentially a named alias for ::outside ( http://www.w3.org/TR/css3-content/#wrapping), which, sadly, has not been implemented anywhere and hasn't seen public movement in quite a long while. From ian at hixie.ch Mon Feb 3 11:42:33 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 3 Feb 2014 19:42:33 +0000 (UTC) Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <op.xapjoreiidj3kv@simons-mbp> References: <52ED9C15.10903@mcc.id.au> <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> <52EF0E40.1080006@mcc.id.au> <CADnb78jwtuKM+W3=+Cgg--J0_3XWN-9QNxO2Do-DfKNS0eAbcA@mail.gmail.com> <op.xapjoreiidj3kv@simons-mbp> Message-ID: <alpine.DEB.2.00.1402031939280.30855@ps20323.dreamhostps.com> On Mon, 3 Feb 2014, Anne van Kesteren wrote: > On Mon, Feb 3, 2014 at 3:34 AM, Cameron McCormack <cam at mcc.id.au> wrote: > > When the document isn't an HTML document and when there is no element > > with focus. Browsers agree on returning null in an HTML document when > > there is no element with focus, no <body> element, but still a > > document element. That case is obscure, though (I mean, it can only happen if you literally replace the <body> or <frameset> element with something else, like a <div>... and while I acknowledge that the Web is a wild, wild place, I doubt there are many pages that actually do that and, on top of that, depend on activeElement returning null). It seems simpler to just try to use "the body element" (as defined in the HTML spec, it's not a <body> necessarily), and if that fails, use the root if there is one or null otherwise. On Mon, 3 Feb 2014, Boris Zbarsky wrote: > > What Gecko does is that if the document is an HTMLDocument (so is > text/html or application/xhtml+xml) and hence has a .body property we > use that. Otherwise we use .documentElement. > > Of course the spec has no concept of HTMLDocument and has a .body on all > documents... Yeah, that would hurt the ability to use HTML from other namespaces (since the HTML helper stuff on the Document would be missing). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Feb 3 11:42:33 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 3 Feb 2014 19:42:33 +0000 (UTC) Subject: [whatwg] Document.activeElement should return the root element in non-HTML documents when no element has focus In-Reply-To: <op.xapjoreiidj3kv@simons-mbp> References: <52ED9C15.10903@mcc.id.au> <CADnb78gkqGxVrgFze-wAiTJAmZ7w8f-==WNQXPzuaUcQMxT+og@mail.gmail.com> <52EF0E40.1080006@mcc.id.au> <CADnb78jwtuKM+W3=+Cgg--J0_3XWN-9QNxO2Do-DfKNS0eAbcA@mail.gmail.com> <op.xapjoreiidj3kv@simons-mbp> Message-ID: <alpine.DEB.2.00.1402031939280.30855@ps20323.dreamhostps.com> On Mon, 3 Feb 2014, Anne van Kesteren wrote: > On Mon, Feb 3, 2014 at 3:34 AM, Cameron McCormack <cam at mcc.id.au> wrote: > > When the document isn't an HTML document and when there is no element > > with focus. Browsers agree on returning null in an HTML document when > > there is no element with focus, no <body> element, but still a > > document element. That case is obscure, though (I mean, it can only happen if you literally replace the <body> or <frameset> element with something else, like a <div>... and while I acknowledge that the Web is a wild, wild place, I doubt there are many pages that actually do that and, on top of that, depend on activeElement returning null). It seems simpler to just try to use "the body element" (as defined in the HTML spec, it's not a <body> necessarily), and if that fails, use the root if there is one or null otherwise. On Mon, 3 Feb 2014, Boris Zbarsky wrote: > > What Gecko does is that if the document is an HTMLDocument (so is > text/html or application/xhtml+xml) and hence has a .body property we > use that. Otherwise we use .documentElement. > > Of course the spec has no concept of HTMLDocument and has a .body on all > documents... Yeah, that would hurt the ability to use HTML from other namespaces (since the HTML helper stuff on the Document would be missing). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Feb 3 11:44:28 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 3 Feb 2014 19:44:28 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: <52EDD11A.5030606@mcc.id.au> References: <52EDD11A.5030606@mcc.id.au> Message-ID: <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> On Sat, 1 Feb 2014, Cameron McCormack wrote: > > Currently, HTML defines Document.title on SVG documents to defer to > whatever the SVG specification defines for SVGDocument.title. The > SVGDocument interface has gone away, so this will need to be updated. > From some basic testing, it looks like SVG needs the same behaviour as > HTML -- first <title> element in the document, plus the white space > collapsing behaviour. > > Do you want to just handle that all in HTML? I'm not sure there's much > value to duplicating either the searching for the title element or the > white space collapsing behaviour in SVG itself. I'm all for handling it in one place. What precisely do you want the behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- "the first <svg:title> element" may come after "the first <html:title> element", and vice versa. Also consider when one or the other is "primary" but the relevant element is absent.) -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Feb 3 11:48:44 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 3 Feb 2014 19:48:44 +0000 (UTC) Subject: [whatwg] Comments on <dialog> In-Reply-To: <CAJGQg4GNQkGLarec32zffTA5Xgc8KRaj2y6LjO6+Mp1H5-A9dQ@mail.gmail.com> References: <CAJ_xCi=dZeocSKh=okFnwVfq15PfXQUNsrtOxLQ4Y1yyM_wQdg@mail.gmail.com> <alpine.DEB.2.00.1308270030250.28417@ps20323.dreamhostps.com> <CANMdWTtM00BSP0qFShRfRXQOa9W-0T6Km+zicxekykqWi2F7WA@mail.gmail.com> <alpine.DEB.2.00.1309261841150.12199@ps20323.dreamhostps.com> <CAJ_xCimEQKk_y1osA1Lm_v2CzkRZdD80T25Q2MubN9G0xFHTpg@mail.gmail.com> <CAO8i3idm+_jg_0-9EJ=4JsmraNHYvwk6zfEL3uTOAG=DwamZyQ@mail.gmail.com> <CAJ_xCikrFgN9jS0hqaU=scypz+i=kM8-iKyL9roZriiss7UHeQ@mail.gmail.com> <alpine.DEB.2.00.1312171758550.27766@ps20323.dreamhostps.com> <CAJGQg4HsVWBtjLYTppm=tKAeENiwvSr08CdbOyzLi57MRtkd2A@mail.gmail.com> <alpine.DEB.2.00.1312181912580.23407@ps20323.dreamhostps.com> <CAJGQg4FSDyDHsZ8gpi3KRahiPreGrXwV4c7rsXmqAuJTJxppNQ@mail.gmail.com> <CAO9Q3iKgRDqp59X5XCcAD=acE33a1M3zRBD8RrcATWYRm7kt9g@mail.gmail.com> <alpine.DEB.2.00.1402010026410.26647@ps20323.dreamhostps.com> <CAJGQg4GNQkGLarec32zffTA5Xgc8KRaj2y6LjO6+Mp1H5-A9dQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1402031946150.30855@ps20323.dreamhostps.com> On Mon, 3 Feb 2014, Brian Blakely wrote: > On Fri, Jan 31, 2014 at 7:31 PM, Ian Hickson <ian at hixie.ch> wrote: > > On Wed, 18 Dec 2013, Brian Blakely wrote: > > > > > > This is what the shadow DOM would look like for modal dialogs: > > > > > > ::modal > > > - ::backdrop > > > - <dialog> > > > > > > ::modal is <dialog>'s ancestor, and is available when showModal is > > > called. This allows authors to set CSS overflow to whichever value > > > suits their use-case, and for user agents to establish overflow: > > > auto as the default, making the dialog inherently pannable when it > > > exceeds the viewport. > > > > That seem somewhat novel, from the CSS perspective. I'll have to defer > > to implementors as to how feasible something like that is. [...] > > ::modal is essentially a named alias for ::outside ( > http://www.w3.org/TR/css3-content/#wrapping), which, sadly, has not been > implemented anywhere and hasn't seen public movement in quite a long > while. Yeah. ::outside is pretty novel also, from a CSS perspective. That might well be why it hasn't gone anywhere since I originally specced it in early 2002/2003. I think it'd be great for it to be implemented, but we're more likely to get there by pushing ::outside than trying to push a special case version of it, I think. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From jonas at sicking.cc Mon Feb 3 11:53:14 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Mon, 3 Feb 2014 11:53:14 -0800 Subject: [whatwg] onclose events for MessagePort In-Reply-To: <alpine.DEB.2.00.1401301806420.26647@ps20323.dreamhostps.com> References: <CANTur_5wOh09o5M65uzaMjbOzeCVWw5862cq8s-5V-jk=NJKpA@mail.gmail.com> <524AFFD0.9040400@helsinki.fi> <CAArhhist8=3Dq_AvpLDK_OD6_KmuNaPg8zTzdv3poGvcapaUQw@mail.gmail.com> <1410130868.1598018.1380715358709.JavaMail.zimbra@mozilla.com> <alpine.DEB.2.00.1312062200280.27766@ps20323.dreamhostps.com> <CANTur_7DNZ4yUT0v0vpkgr0puCJG+ePkk-cd+8oz_wXUhVm_Lw@mail.gmail.com> <alpine.DEB.2.00.1312111759180.27766@ps20323.dreamhostps.com> <CA+c2ei_cBi8Y3yVjf50EMFhtD5h=CYWvz+_H-SjV4VhzErZcxg@mail.gmail.com> <alpine.DEB.2.00.1312112345560.26758@ps20323.dreamhostps.com> <CA+c2ei-22s2C7JRvCc4gMXKTwLBdP8XWai38t9-6YBjpaQ8i4A@mail.gmail.com> <CA+c2ei-HRv8rQWpse41Fu4pFg1w_ZO2qbdAAF3v_rV4P=5h7FQ@mail.gmail.com> <alpine.DEB.2.00.1312132208150.27766@ps20323.dreamhostps.com> <CA+c2ei_9UU0JKNv8-_V3ae04StgmcjG-Xrcgw_LdTJ8go=Nikw@mail.gmail.com> <alpine.DEB.2.00.1401301806420.26647@ps20323.dreamhostps.com> Message-ID: <CA+c2ei_Yuywghk12GO9Rdhe=_TGrtX2d_f1_-sfuWskifoqiNQ@mail.gmail.com> On Thu, Jan 30, 2014 at 11:41 AM, Ian Hickson <ian at hixie.ch> wrote: > On Fri, 13 Dec 2013, Jonas Sicking wrote: >> On Fri, Dec 13, 2013 at 3:29 PM, Ian Hickson <ian at hixie.ch> wrote: >> > On Wed, 11 Dec 2013, Jonas Sicking wrote: >> >> No sync IPC needed. When a port is pinned, you send an async message >> >> to the process which contains the page for the "other side". When >> >> that process receives the message you check if the page is currently >> >> being displayed. >> >> >> >> If the page has been completely torn down then you send a message >> >> back saying that the page is dead and that the promise created during >> >> pinning should be rejected. >> >> >> >> If the page is sitting in the bfcache, you remove it from the bfcache >> >> and send a message back saying that the page is dead and that the >> >> promise created during pinning should be rejected. >> >> >> >> If the page is displayed, then you add a flag indicating that if the >> >> page is navigated away from, it should not go into the bfcache and >> >> that we should send a signal to reject the promise. >> >> >> >> Obviously if the process had crashed before we were able to process >> >> the event, you send a message back to reject the promise. >> >> >> >> The same thing is done when unpinning. You send a message to the >> >> other side saying that it's getting unpinned. >> > >> > This means that it's possible to get a lock, have the other side >> > navigate then go back, then have the other side receive the >> > notification for the lock. It's this that you need blocking IPC to >> > prevent. But I guess we could live with that just being possible. >> >> Indeed. The idea with bfcache is that going back/forward should be >> largely transparent to the page itself. So I think it's fine that it's >> transparent also to the page that's talking to it in this instance. >> >> Kicking the page out of bfcache isn't a goal in and of itself. The goal >> is to prevent other pages from waiting unduly long for a message. > > This basically boils down to being able to flip a switch on a MessagePort > saying that the port should not be GC'ed and should prevent its owner's > pages from being bfcached, right? I'm still very uncomfortable with this > idea of preventing either of these. Having a way to prevent GC on objects > that would otherwise get GC'ed seems like it would result in leaks, and > preventing bfcache seems like it would defeat the entire bfcache idea > (consider what happens if some ad networks start using shared workers to > make obtaining and showing ads more efficient, and they communicate with > the host pages with ports that they block bfcache on -- suddently large > parts of the Web would have bfcache defeated). I agree that being able to prevent an object from getting GCed isn't great, however any solution in this space is going to require the UA to retain a bit more memory. The reason that we need to retain the MessagePort object in the solutions discussed so far is that we've tried to fire the event on the MessagePort object itself. If we instead fired an event on the global indicating "the other side has gone away", then a MessagePort doesn't need to be retained. However such a solution requires a different way to identify which communication channel was severed. We could allow naming ports and then the name of the port would be included in the "lost connection to an other side". Of course, that requires keeping that name in memory which is arguably as leaky. Or we could come up with numeric port identifiers, in which case less memory is "leaked". Another way to reduce leaks would be to not have explicit API for locking and releasing a port. Instead you could indicate with a sent message that a response is expected, and then allow the other side to explicitly respond to the message, at which case the port would be automatically released. This is in theory just as leaky, however the syntax might encourage fewer leaks in practice. Another thing that could help is to expose a property somewhere which contains a list of the currently un-GCable ports. This way a page could on a regular basis inspect if it has leaked any ports and clean them up. I'm happy to explore any of these options. Ultimately though trying to aim for "no leaks" isn't really a well defined goal. The bfcache issue is solvable as discussed. >> We could allow bfcaching here by introducing the discussed separate >> features which allow the page to signal that it's fine with being >> bfcached even though the error was signaled. That way if the page is >> revived from bfcache it can send a message on the channel saying "I'm >> back now" at which point they can resume communicating. > > How would this work when a page has several libraries (e.g. ads, Facebook > like button, Twitter tweet button), each talking to their shared worker, > and each with different opinions about whether or not they can handle a > bfcache situation? As soon as any of them can't deal with bfcache the page won't be bfcached. I.e. you could add an API which indicates "I'm currently talking through this MessagePort object. But still let me go into bfcache." If all MessagePorts are accounted for, the page can go into bfcache. If a single port is not accounted for, the page does not get bfcached. > What the spec has now (MessagePort.onerror) only helps for the limited > case of a process getting killed by the system; it doesn't help for any of > the features of the Web platform like navigation, Worker.terminate(), etc. > > Maybe the right thing here is for you (browser vendors) to experiment with > different approaches to this, and for me to just spec whatever comes out > of that. I'm happy to experiment. In the meantime I would ask that MessagePort.onerror is removed as I don't think any browser vendor has expressed a desire to implement. / Jonas From ian at hixie.ch Mon Feb 3 12:29:59 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 3 Feb 2014 20:29:59 +0000 (UTC) Subject: [whatwg] onclose events for MessagePort In-Reply-To: <CA+c2ei_Yuywghk12GO9Rdhe=_TGrtX2d_f1_-sfuWskifoqiNQ@mail.gmail.com> References: <CANTur_5wOh09o5M65uzaMjbOzeCVWw5862cq8s-5V-jk=NJKpA@mail.gmail.com> <524AFFD0.9040400@helsinki.fi> <CAArhhist8=3Dq_AvpLDK_OD6_KmuNaPg8zTzdv3poGvcapaUQw@mail.gmail.com> <1410130868.1598018.1380715358709.JavaMail.zimbra@mozilla.com> <alpine.DEB.2.00.1312062200280.27766@ps20323.dreamhostps.com> <CANTur_7DNZ4yUT0v0vpkgr0puCJG+ePkk-cd+8oz_wXUhVm_Lw@mail.gmail.com> <alpine.DEB.2.00.1312111759180.27766@ps20323.dreamhostps.com> <CA+c2ei_cBi8Y3yVjf50EMFhtD5h=CYWvz+_H-SjV4VhzErZcxg@mail.gmail.com> <alpine.DEB.2.00.1312112345560.26758@ps20323.dreamhostps.com> <CA+c2ei-22s2C7JRvCc4gMXKTwLBdP8XWai38t9-6YBjpaQ8i4A@mail.gmail.com> <CA+c2ei-HRv8rQWpse41Fu4pFg1w_ZO2qbdAAF3v_rV4P=5h7FQ@mail.gmail.com> <alpine.DEB.2.00.1312132208150.27766@ps20323.dreamhostps.com> <CA+c2ei_9UU0JKNv8-_V3ae04StgmcjG-Xrcgw_LdTJ8go=Nikw@mail.gmail.com> <alpine.DEB.2.00.1401301806420.26647@ps20323.dreamhostps.com> <CA+c2ei_Yuywghk12GO9Rdhe=_TGrtX2d_f1_-sfuWskifoqiNQ@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1402032023590.30855@ps20323.dreamhostps.com> On Mon, 3 Feb 2014, Jonas Sicking wrote: > > I agree that being able to prevent an object from getting GCed isn't > great, however any solution in this space is going to require the UA to > retain a bit more memory. The reason that we need to retain the > MessagePort object in the solutions discussed so far is that we've tried > to fire the event on the MessagePort object itself. If we instead fired > an event on the global indicating "the other side has gone away", then a > MessagePort doesn't need to be retained. > > However such a solution requires a different way to identify which > communication channel was severed. We could allow naming ports and then > the name of the port would be included in the "lost connection to an > other side". Of course, that requires keeping that name in memory which > is arguably as leaky. Or we could come up with numeric port identifiers, > in which case less memory is "leaked". I think this would just result in authors keeping track of the ports in an index, which would prevent them from being GC'ed, which defeats the point. > The bfcache issue is solvable as discussed. > [...] > As soon as any of them can't deal with bfcache the page won't be > bfcached. I don't think "solvable" is the same as "design an API that basically guarantees that within a decade most of the Web won't be bfcached". > I'm happy to experiment. In the meantime I would ask that > MessagePort.onerror is removed as I don't think any browser vendor has > expressed a desire to implement. Done. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Mon Feb 3 15:39:13 2014 From: ian at hixie.ch (Ian Hickson) Date: Mon, 3 Feb 2014 23:39:13 +0000 (UTC) Subject: [whatwg] inputmode feedback In-Reply-To: <20140203101426.GE35206@sideshowbarker> References: <83D6DB4D-DC3B-483D-9FD9-62D182D20F1A@apple.com> <alpine.DEB.2.00.1309170032060.12199@ps20323.dreamhostps.com> <CAAEV3pnU8aC7vFua6x0ryqtJtH5O0sNqtvpW6c5E7bVnqdgVnQ@mail.gmail.com> <20131206092729.GA95292@sideshowbarker> <CADP2=ho0di2Pu-mVveZ+iubT9Ekns+L+64_n+oygUK4wX7c33Q@mail.gmail.com> <20131206133045.GD95292@sideshowbarker> <B090F654-6B1D-46E7-AA63-B94DB6CCEA8C@apple.com> <CADP2=hqJR_zg5z=24a3qigicKWThkF4HJ-ayEz3xgg-Lh9p-gw@mail.gmail.com> <20131216093615.GI32206@sideshowbarker> <alpine.DEB.2.00.1401220032560.26647@ps20323.dreamhostps.com> <20140203101426.GE35206@sideshowbarker> Message-ID: <alpine.DEB.2.00.1402032325460.26647@ps20323.dreamhostps.com> On Mon, 3 Feb 2014, Michael[tm] Smith wrote: > Ian Hickson <ian at hixie.ch>, 2014-01-22 00:54 +0000: > > > > The idea of the inputmode="" attribute is that it gives the mode that > > is most likely to be needed by the user when providing input. There's > > various modes that seem to make sense: > > > > - inserting raw latin-script characters, like passwords, product > > codes > > > > - inserting human-readable latin-script short-form text, like search > > queries > > > > - inserting human-readable latin-script human names > > > > - inserting human-readable latin-script long-form text, like blog > > posts > > > > - inserting numeric data, like credit card numbers > > > > - inserting text in other scripts, of which I know nothing > > > > - inserting human-readable latin-script text within long-form text in > > other scripts > > > > You don't use the same kind of keyboard for inserting raw latin-script > > characters as for inserting Japanese long-form prose, so it makes > > sense to me that they'd use different input modes. > > > > Why is this wrong? > > I personally think it's not wrong. Well, mostly not wrong, at least (see > below for what I think is one specific, fixable problem.) But I believe > one objection that others have made to the current set of modes is that > for Latin input it provides values that conflate typing-aids hints with > the script hint, while for Japanese input, it does not. Well, nobody has suggested that there are any typing aid hints applicable to Japanese input yet. The current list for Japanese (and all non-Latin- script languages) are just the list of input modes people told me were needed (since nobody has asked for anything for anything but Japanese and Latin-script languages, there's nothing for those). > That means there's at least one possibly-useful mode that inputmode > currently does make expressible: a "name" mode for kana input (to > correspond to the latin-name mode). Added. > What I mean is, what value would an author choose if they wanted to > indicate a mode for inserting human-readable kana-input human names? As of now, "kana-name". > Asking that question makes me realize that we probably don't actually > want a "-name" mode for the contact-list case anyway -- because a > Japanese user is likely to have a contact list that contains names both > in Kanji and in Latin characters. So if we really want to provide "text > prediction from the user's contact list", I think we'd probably want to > just add an script-less inputmode=contact value for that. If there was going to be a "keyboard" that consisted primarily of a contact list, I'd agree. But the keyboard will be a keyboard, and it'll autocomplete from a contact list. And thus that keyboard needs a default mode to be in. If all my friends have Latin-script names, it is inconvenient if the keyboard starts with a Russian keyboard. I presume, based on what you suggested above, that a Japanese user would find it more helpful if their keyboard started in a mode for "kana or romaji input, typically hiragana input". > Also, there are things other than human names for which namecase (aka > titlecase) is useful: For example, a field where the user is expected to > type in a book title or movie title. For those kinds of fields, you > clearly wouldn't want "text prediction from the user's contact list" > turned on also. Instead you'd just want it to be inputmode=titlecase. If users actually want auto-title-casing, then yes, we could introduce a "latin-title-case" mode, or something like that. Do they? I haven't heard of a request for this so far. > Anyway, I think the root problem might be that we have > inputmode=latin-name to begin with. I don't understand why it's a problem. > So I'd suggest either dropping it entirely, or replacing it with the two > new values inputmode=titlecase and inputmode=contact. That wouldn't give the UA the information the UA needs to pick the right keyboard. > And as far as using inputmode for specifying typing aids instead of just > script, I don't what other kinds of typing aids (other than the contact > case) would be relevant for Japanese input. The main typing aids the > spec mentions are autocapitalization, autocorrect, and text prediction. > Among those, capitalization isn't relevant for Japanese input at all. > And as far as autocorrect, in my experience at least, autocorrect isn't > a feature that's commonly used anywhere with IMEs for Japanese input, so > it's not relevant. And as far as text prediction, in Japanese IMEs text > prediction is always turned on anyway, and I can't think of cases where > a user would really care to have it turned off (or be bothered by having > it on). Right, each script has different needs. That's why these are not orthogonal concerns; they're input modalities. I don't know anything about what input modalities are needed outside of Latin script keyboards, so I rely on people reporting what is missing so that I can add it. > Come to think of it, in soft keyboards on smartphones for Latin input too, > text prediction is always on anyway. Not always. For example, you wouldn't want to have it on in a password field or URL field. > So maybe these days there's not much of a real need to provide a hint > for a "text prediction on" typing aid -- because "text prediction on" is > the default anyway. Maybe instead there's now more of a need for a "text > prediction off" typing aid, I dunno. The spec doesn't have a default mode and an "on" mode (or "off" mode), it just has various different modes, some with and some without certain features (or rather, hints as to whether those features should be there or not by default). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cam at mcc.id.au Mon Feb 3 16:25:09 2014 From: cam at mcc.id.au (Cameron McCormack) Date: Tue, 04 Feb 2014 11:25:09 +1100 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> Message-ID: <52F03365.5050004@mcc.id.au> Ian Hickson wrote: > I'm all for handling it in one place. What precisely do you want the > behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- "the first > <svg:title> element" may come after "the first<html:title> element", and > vice versa. Also consider when one or the other is "primary" but the > relevant element is absent.) OK, how about: if the document element is an <html:html>, we choose the first <html:title> in document order; if the document element is an <svg:svg>, we choose the first child <svg:title> of the document element; otherwise, null. This still is going to produce "incorrect" results for things like: <!DOCTYPE html> <svg> <foreignObject> <title>blah but arguably you shouldn't be using in there anyway. From jonas at sicking.cc Mon Feb 3 16:59:49 2014 From: jonas at sicking.cc (Jonas Sicking) Date: Mon, 3 Feb 2014 16:59:49 -0800 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <52F03365.5050004@mcc.id.au> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> Message-ID: <CA+c2ei9gt0jfOah9d-Wv6AfdVH__EzaE_v3xHmdWquX6MBjNzA@mail.gmail.com> On Mon, Feb 3, 2014 at 4:25 PM, Cameron McCormack <cam at mcc.id.au> wrote: > Ian Hickson wrote: >> >> I'm all for handling it in one place. What precisely do you want the >> behaviour to be? (Consider HTML-in-SVG and SVG-in-HTML also -- "the first >> <svg:title> element" may come after "the first<html:title> element", and >> vice versa. Also consider when one or the other is "primary" but the >> relevant element is absent.) > > > OK, how about: if the document element is an <html:html>, we choose the > first <html:title> in document order; if the document element is an > <svg:svg>, we choose the first child <svg:title> of the document element; > otherwise, null. An even simpler solution would be to say "we choose the first <html:title> or <svg:title> in document order". That has the nice property that we align SVG and HTML more. / Jonas From cam at mcc.id.au Mon Feb 3 17:02:34 2014 From: cam at mcc.id.au (Cameron McCormack) Date: Tue, 04 Feb 2014 12:02:34 +1100 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <CA+c2ei9gt0jfOah9d-Wv6AfdVH__EzaE_v3xHmdWquX6MBjNzA@mail.gmail.com> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CA+c2ei9gt0jfOah9d-Wv6AfdVH__EzaE_v3xHmdWquX6MBjNzA@mail.gmail.com> Message-ID: <52F03C2A.7060806@mcc.id.au> Jonas Sicking wrote: > An even simpler solution would be to say "we choose the first > <html:title> or<svg:title> in document order". That has the nice > property that we align SVG and HTML more. Although as Dirk pointed out, SVG distinguishes <title> elements that are children of the root element vs children of other elements. The <title> that is a child of the root element gives the title of the entire element, while a <title> child of another element in the document describes only that element (like title="" does in HTML). From cabanier at gmail.com Mon Feb 3 21:47:38 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Mon, 3 Feb 2014 21:47:38 -0800 Subject: [whatwg] hit regions: moving an element out of the shadow tree Message-ID: <CAGN7qDArBxaMKq_2TUHWH+0JEkGqKCr+PXZgR_w62gyvfgLMkQ@mail.gmail.com> The spec is currently silent what should happen when an element that is associated with a hit region, is moved to another location in the document, another document or deleted. This should result in removal of the hit region. Maybe this is defined in the HTML spec? From annevk at annevk.nl Tue Feb 4 03:05:44 2014 From: annevk at annevk.nl (Anne van Kesteren) Date: Tue, 4 Feb 2014 11:05:44 +0000 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <52F03365.5050004@mcc.id.au> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> Message-ID: <CADnb78gWL-Le2SUcOSixnovYPGKueigUzA2bV4tUOwjnoaK_ZQ@mail.gmail.com> On Tue, Feb 4, 2014 at 12:25 AM, Cameron McCormack <cam at mcc.id.au> wrote: > OK, how about: if the document element is an <html:html>, we choose the > first <html:title> in document order; if the document element is an > <svg:svg>, we choose the first child <svg:title> of the document element; > otherwise, null. This seems good. > This still is going to produce "incorrect" results for things like: > > <!DOCTYPE html> > <svg> > <foreignObject> > <title>blah > > Given that this does not define a html:title in html:head it's non-conforming anyway so that seems fine. (I'm assuming we're using HTML parsing rules of today.) -- http://annevankesteren.nl/ From ian at hixie.ch Tue Feb 4 09:13:24 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 4 Feb 2014 17:13:24 +0000 (UTC) Subject: [whatwg] hit regions: moving an element out of the shadow tree In-Reply-To: References: Message-ID: On Mon, 3 Feb 2014, Rik Cabanier wrote: > > The spec is currently silent what should happen when an element that is > associated with a hit region, is moved to another location in the > document, another document or deleted. > > This should result in removal of the hit region. Maybe this is defined > in the HTML spec? It results in the region no longer having a backing control (see the definition of "the control represented by a region"), but why would it remove the region? The region might be there for other reasons, e.g. it might have a cursor or ID specified, or the author might be using it to play a sound when the user tries to click on the space where the control used to be drawn, to indicate to the user that the control is gone. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From ian at hixie.ch Tue Feb 4 09:15:16 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 4 Feb 2014 17:15:16 +0000 (UTC) Subject: [whatwg] Document.title for SVG documents In-Reply-To: References: <52EDD11A.5030606@mcc.id.au> <52F03365.5050004@mcc.id.au> Message-ID: On Tue, 4 Feb 2014, Anne van Kesteren wrote: > > Given that this does not define a html:title in html:head it's > non-conforming anyway so that seems fine. (I'm assuming we're using HTML > parsing rules of today.) The spec actually allows to be ommitted in a number of cases, e.g. srcdoc documents, and we may extend this in the future (e.g. documents intended only for use in <iframe>s). -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From cabanier at gmail.com Tue Feb 4 10:31:18 2014 From: cabanier at gmail.com (Rik Cabanier) Date: Tue, 4 Feb 2014 10:31:18 -0800 Subject: [whatwg] hit regions: moving an element out of the shadow tree In-Reply-To: <alpine.DEB.2.00.1402041708350.30855@ps20323.dreamhostps.com> References: <CAGN7qDArBxaMKq_2TUHWH+0JEkGqKCr+PXZgR_w62gyvfgLMkQ@mail.gmail.com> <alpine.DEB.2.00.1402041708350.30855@ps20323.dreamhostps.com> Message-ID: <CAGN7qDBr5E2Jbbdxpnff=0inQwoLcUrSzjapTwSFQFZfhDza9w@mail.gmail.com> On Tue, Feb 4, 2014 at 9:13 AM, Ian Hickson <ian at hixie.ch> wrote: > On Mon, 3 Feb 2014, Rik Cabanier wrote: > > > > The spec is currently silent what should happen when an element that is > > associated with a hit region, is moved to another location in the > > document, another document or deleted. > > > > This should result in removal of the hit region. Maybe this is defined > > in the HTML spec? > > It results in the region no longer having a backing control (see the > definition of "the control represented by a region"), but why would it > remove the region? The region might be there for other reasons, e.g. it > might have a cursor or ID specified, or the author might be using it to > play a sound when the user tries to click on the space where the control > used to be drawn, to indicate to the user that the control is gone. Ok, link: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-control-represented-by-a-region It's a bit weird that you can do "ctx.addHitRegion({});" :-) From ian at hixie.ch Tue Feb 4 11:05:01 2014 From: ian at hixie.ch (Ian Hickson) Date: Tue, 4 Feb 2014 19:05:01 +0000 (UTC) Subject: [whatwg] hit regions: moving an element out of the shadow tree In-Reply-To: <CAGN7qDBr5E2Jbbdxpnff=0inQwoLcUrSzjapTwSFQFZfhDza9w@mail.gmail.com> References: <CAGN7qDArBxaMKq_2TUHWH+0JEkGqKCr+PXZgR_w62gyvfgLMkQ@mail.gmail.com> <alpine.DEB.2.00.1402041708350.30855@ps20323.dreamhostps.com> <CAGN7qDBr5E2Jbbdxpnff=0inQwoLcUrSzjapTwSFQFZfhDza9w@mail.gmail.com> Message-ID: <alpine.DEB.2.00.1402041903120.30855@ps20323.dreamhostps.com> On Tue, 4 Feb 2014, Rik Cabanier wrote: > On Tue, Feb 4, 2014 at 9:13 AM, Ian Hickson <ian at hixie.ch> wrote: > > On Mon, 3 Feb 2014, Rik Cabanier wrote: > > > > > > The spec is currently silent what should happen when an element that > > > is associated with a hit region, is moved to another location in the > > > document, another document or deleted. > > > > > > This should result in removal of the hit region. Maybe this is > > > defined in the HTML spec? > > > > It results in the region no longer having a backing control (see the > > definition of "the control represented by a region"), but why would it > > remove the region? The region might be there for other reasons, e.g. > > it might have a cursor or ID specified, or the author might be using > > it to play a sound when the user tries to click on the space where the > > control used to be drawn, to indicate to the user that the control is > > gone. > > Ok, link: > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#the-control-represented-by-a-region > > It's a bit weird that you can do "ctx.addHitRegion({});" :-) Or even just c.addHitRegion(). An author might want to do that to introduce a "dead" zone in a canvas, where the cursor reverts to the canvas default cursor, there's no AT implications, and the hit testing in mouse events doesn't give a region ID any more. This is similar to <area> elements with no href="". -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' From dschulze at adobe.com Tue Feb 4 13:46:02 2014 From: dschulze at adobe.com (Dirk Schulze) Date: Tue, 4 Feb 2014 21:46:02 +0000 Subject: [whatwg] Document.title for SVG documents In-Reply-To: <52F03C2A.7060806@mcc.id.au> References: <52EDD11A.5030606@mcc.id.au> <alpine.DEB.2.00.1402031943100.30855@ps20323.dreamhostps.com> <52F03365.5050004@mcc.id.au> <CA+c2ei9gt0jfOah9d-Wv6AfdVH__EzaE_v3xHmdWquX6MBjNzA@mail.gmail.com> <52F03C2A.7060806@mcc.id.au> Message-ID: <64E30974-91F0-462A-998F-D521B78627EE@adobe.com> On Feb 3, 2014, at 5:02 PM, Cameron McCormack <cam at mcc.id.au> wrote: > Jonas Sicking wrote: >> An even simpler solution would be to say "we choose the first >> <html:title> or<svg:title> in document order". That has the nice >> property that we align SVG and HTML more. > > Although as Dirk pointed out, SVG distinguishes <title> elements that are children of the root element vs children of other elements. The <title> that is a child of the root element gives the title of the entire element, while a <title> child of another element in the document describes only that element (like title="" does in HTML). You should compare screenreader output on IE and Firefox for Windows. SVG does differ titles in terms of hierarchy. The first <title>/<desc> element in the first hierarchy level after <svg> root is taken as title/description of the ?document?. Document in the meaning that the outermost SVG root creates an SVG document. Any hierarchy after the first is the title/description of the group. Here two examples with inline description: <svg> <title>This is the title of the document The