[whatwg] IE10 inconsistency with Blob / createObjectURL
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
Re: [whatwg] Comments on
On Wed, 18 Dec 2013, Brian Blakely wrote: > On Wed, Dec 18, 2013 at 2:13 PM, Ian Hickson wrote: > > On Wed, 18 Dec 2013, Brian Blakely wrote: > > > On Tue, Dec 17, 2013 at 3:14 PM, Ian Hickson 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 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 . > > > > Not really sure how this would work. Can you elaborate? > > This is what the shadow DOM would look like for modal dialogs: > > ::modal > - ::backdrop > - > > ::modal is '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: On Thu, 19 Dec 2013, Elliott Sprehn wrote: > > We can't implement that inside Blink. It requires to have two > parents, the real one in the DOM and ::modal. The only way I can see > this working is if we special case the Shadow DOM projection logic for > so that it is always projected into ::modal, but we don't want > any special cases in projection. I've not put this ::modal model in the spec. On Wed, 18 Dec 2013, Brian Blakely wrote (continuing from above): > > > > > > > 3. When the modal dialog's height changes, either due to CSS > > > > > > > or content changes, the vertical position of the dialog > > > > > > > should change (unless the height exceeds the viewport > > > > > > > height). > > > > > > > > > > > > That's an interesting idea, but I'm not convinced it's the > > > > > > right answer. Having the dialog move up and down when stuff is > > > > > > added at the bottom would be quite weird. You can always > > > > > > implement this manually from script. > > > > > > > > > > To go back to hacky and rather difficult-to-maintain JS > > > > > techniques for something so simple seems antithetical to the > > > > > intention of to me. Modern modal implementations don't > > > > > require that. > > > > > > > > My point isn't that we shouldn't offer the feature because it is > > > > already possible. My point is that this feature is actively bad. > > > > I'm saying I don't think it's good UI for the dialog position to > > > > change when it increases in height. > > > > > > It looks like Blink's implementation will recenter the modal when > > > show/showModal are called. > > > > That's per spec, yes. The suggestion above was regarding when the > > dialog changes size while it's already visible, I believe. > > You're correct. I was pointing out that there is already a means of > recentering, albeit indirectly. I could see this being abused by > "clever" hackers, with dialog.close() and dialog.showModal() being > called in rapid succession, simply for the purpose of recentering. Sure. As noted above, you could do it from script if you wanted. I was only objecting to supporting it directly, since it doesn't seem like a good user interface. Obviously, authors have found many ways to create poor interfaces over the years, even without explicit support. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] inverse property mechanism for Microdata?
On Fri, 31 Jan 2014, Dan Brickley wrote: > > We'd (schema.org 'we') like to make a public proposal to update > Microdata with a syntax for expressing inverse properties/relationships. > [...] > > Here's an example with 'containedIn'. The idea is that we want to > express that the LocalBusiness (i.e. Place) Entity B is 'containedIn' > Entity A. The example I show here expresses the reverse, incorrectly. So > we're looking for a change to the markup that would turn this example > into one that said "The LocalBusiness Entity B is containedIn the > LocalBusiness Entity A": > > http://schema.org/LocalBusiness";> > (Entity A) Beachwalk Beachwear & > Giftware >A superb collection of fine gifts and clothing > to accent your stay in Mexico Beach. > Phone: 850-648-4200 > > itemtype="http://schema.org/LocalBusiness";> > (Entity B) The tiny store within a > store > A superb collection of tiny clothes, > from the store within the store. > Phone: 123-456-7890 > > > This is actually possible today: http://schema.org/LocalBusiness"; id=a itemprop="containedIn"> (Entity A) Beachwalk Beachwear & Giftware A superb collection of fine gifts and clothing to accent your stay in Mexico Beach. Phone: 850-648-4200 http://schema.org/LocalBusiness";> (Entity B) The tiny store within a store A superb collection of tiny clothes, from the store within the store. Phone: 123-456-7890 The trick here is to turn the inner item into the top-level microdata item, and use itemref="" to have that inner item point to the outer item. (This works great unless you want two items to refer to the same third item using different properties, but that's something microdata can't do in general, since it's based on a tree structure, not a graph structure. To address that particular problem, you need a vocabulary that defines how itemid="" works; at that point, you can just have the same underlying item represented as multiple microdata items in the document by having all the items share the same ID. But how exactly that is to be interpreted is something the vocabulary has to define.) > One response is that the markup could be reorganized. That's basically what the above does, but without moving the elements around in the DOM. (itemref="" is basically all about making the microdata model work around constraints coming from the author's preferred DOM.) > Another reasonable response to this is 'well, perhaps you should have a > property (instead or in addition) called "geospatiallyContains", or > "containerOf" or "contains", or "rev_containedIn" for this usage > scenario'? That is another option, similar to the parenthetical itemid="" note above -- you could just have the vocabulary define that for every property whose value is an item, the item type that that property can point to has another property with the same name plus a fixed suffix, like "-inv", that inverses the relationship. That would make the above look like: http://schema.org/LocalBusiness";> (Entity A) Beachwalk Beachwear & Giftware A superb collection of fine gifts and clothing to accent your stay in Mexico Beach. Phone: 850-648-4200 http://schema.org/LocalBusiness";> (Entity B) The tiny store within a store A superb collection of tiny clothes, from the store within the store. Phone: 123-456-7890 > We have tried this and in a few cases we have included pairs of inverse > properties in schema.org, e.g. we have "alumni" and an inverse, > "alumniOf". In designing schemas we have found it consistently hard to > get even a single natural/intuitive name for each property, and finding > a good name for the inverse of each makes the task even heavier. > Appending "Of" (or other fixed suffix) doesn't always work well; e.g. > "containedIn" / "containedInOf" barely makes sense. Yeah, you'd have to just pick a suffix like "-inv" or a prefix like "rev-" or something that doesn't attempt to give a good English meaning. The advantage of doing that is that you could then define this for the vocabulary generically, and process it generically, rather than having to actually define and support each individual property. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Locale Preferences API
On Thu, 12 Dec 2013, Jungshik Shin (신정식, 申政湜) wrote: > 2013/11/27 Boris Zbarsky > > On 11/27/13 4:28 PM, Jungshik Shin (신정식, 申政湜) wrote: > > > >> That is, I suggest that 'navigator.language' always be the UI > >> language of a web browser. > > > > That's an unacceptable privacy leak from Mozilla's point of view. > > See https://bugzilla.mozilla.org/show_bug.cgi?id=55366 where we > > explicitly switched from that to basing navigator.language on the > > Accept header. > > Well, the vast majority of users would never touch A-L list. So, the top > entry in the A-L list would remain the default value, which is usually > the UI language. So, I don't know how much your change helps privacy if > revealing the UI language is indeed a valid privacy concern. On Fri, 13 Dec 2013, Boris Zbarsky wrote: > > The point is, the Accept-Languages header already reveals whatever it > reveals, so there is no additional privacy leak from navigator.language > if you just mirror what the header. And for people who _do_ change the > A-L list, they get it picked up in both places automatically. It does seem reasonable that the three APIs (the header and the two IDL attributes, one giving one value and the other a list) would expose the same information, or at least subsets thereof (for the single value one). Jungshik, is there any particular reason for _not_ doing this? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] inverse property mechanism for Microdata?
Hi folks. I'm relaying this from the schema.org collaboration, probably the main user of HTML's Microdata mechanism. We'd (schema.org 'we') like to make a public proposal to update Microdata with a syntax for expressing inverse properties/relationships. FWIW other notations that schema.org supports (JSON-LD and RDFa) have such mechanisms ([1],[2]). At schema.org we are repeatedly running into situations where we have a need for properties to be used in reverse direction. There are 630 or so properties defined currently (and a similar number of types); see listing at http://schema.org/docs/full.html. Inverse properties are relatively a cornercase, but a persistent one. By inverse, I refer to scenarios where there are any pair of properties (relationship types) e.g. "foo" and "bar", such that whenever some entity-1 has a foo relationship to an entity-2, then by definition, entity-2 will have a "bar" relationship to entity-1. We'd like to avoid the need to give "bar" a specific name, and instead be able to in effect just say "the inverse of foo". e.g. perhaps entity-1 is a shop, entity-2 is another shop, and "foo" = "containedIn", "bar" = "containsWithin", indicating that the one shop is inside the other. Or perhaps entity-1 is a school, entity-2 is a celebrity, and foo="alumni", bar="alumniOf". Schema.org would like Microdata syntax to be extended somehow, to allow a single property name to be used regardless of whether the markup nesting structure emphasises entity-1 or entity-2. For more example topics, here are some of the properties we define. http://schema.org/containedIn (which relates a smaller place to a larger containing place); http://schema.org/member http://schema.org/alumni http://schema.org/author http://schema.org/performerIn http://schema.org/worksFor http://schema.org/employee http://schema.org/founder http://schema.org/member ... and various others, often role-related or where two independent entities have a relationship that is being described, and where neither entity is necessarily the primary focus in all markup. For a property like "alumni" it could reasonably be used either in a paragraph that was describing the educational institution, or describing a (famous) person who attended it. We would like to have a standard markup convention for using a single named property, i.e. being able to indicate sometimes that it is to be read in reversed direction. In other words we want to avoid having to come up with two different names for each of these situations; and more importantly, to avoid publishers/authors having to remember two names for one situation. Here's an example with 'containedIn'. The idea is that we want to express that the LocalBusiness (i.e. Place) Entity B is 'containedIn' Entity A. The example I show here expresses the reverse, incorrectly. So we're looking for a change to the markup that would turn this example into one that said "The LocalBusiness Entity B is containedIn the LocalBusiness Entity A": http://schema.org/LocalBusiness";> (Entity A) Beachwalk Beachwear & Giftware A superb collection of fine gifts and clothing to accent your stay in Mexico Beach. Phone: 850-648-4200 http://schema.org/LocalBusiness";> (Entity B) The tiny store within a store A superb collection of tiny clothes, from the store within the store. Phone: 123-456-7890 One response is that the markup could be reorganized. For example, http://schema.org/LocalBusiness";> (Entity B) The tiny store within a store A superb collection of tiny clothes, from the store within the store. Phone: 123-456-7890 http://schema.org/LocalBusiness";> (Entity A) Beachwalk Beachwear & Giftware A superb collection of fine gifts and clothing to accent your stay in Mexico Beach. Phone: 850-648-4200 We're not so optimistic about this approach, especially when multiple entities are described. Schema.org is widely used but seems generally to be added to existing pages with relatively fixed structure. Another reasonable response to this is 'well, perhaps you should have a property (instead or in addition) called "geospatiallyContains", or "containerOf" or "contains", or "rev_containedIn" for this usage scenario'? We have tried this and in a few cases we have included pairs of inverse properties in schema.org, e.g. we have "alumni" and an inverse, "alumniOf". In designing schemas we have found it consistently hard to get even a single natural/intuitive name for each property, and finding a good name for the inverse of each makes the task even heavier. Appending "Of" (or other fixed suffix) doesn't always work well; e.g. "containedIn" / "containedInOf" barely makes sense. In recent work on sports schemas and schemas for reservations there has been pressure to have relationship types work in both directions. Rather than make dozens of arbitrary pairs of named relationships, which each need to be carefully named, remembered, and translate
