Re: [whatwg] Effect on window.opener when navigating an existing window using window.open
On Mon, 3 Mar 2014, Bob Owen wrote: The spec [...] seems to be fairly clear that if an existing window is navigated using window.open, by a browsing context that is not the original opener, then window.opener should remain unchanged. Currently, Trident (and incidentally Presto) seems to have the correct behaviour, but Blink, WebKit and Gecko all change window.opener to the window of the browsing context that has just caused it to navigate. I believe this to be a very long standing difference (10 years for Gecko and Trident) I am proposing to change Gecko to match the spec, but I was advised to raise the issue here before going ahead. Do people agree that window.opener should remain unchanged in this circumstance? Did you receive any off-list feedback on this, or attempt to implement it and get any implementation experience? Having opener be the actual opener seems pretty intuitive to me; if there's no compat need to do otherwise, it seems like a reasonable choice. Is there a security reason to prefer the latest navigator? (At the time the spec was written, it was 2v2; the 1v3 situation we have now is the result of Presto going away and Blink forking from WebKit.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Media sink device selection on audio/video
On Mon, 3 Mar 2014, Ami Fischman wrote: Looks like we're back in business: Latest editor's draft: http://dev.w3.org/2011/webrtc/editor/getusermedia.html Thanks. As a user, this scares me a lot. Why isn't it up to me to control this? I don't understand the security model here at all. I don't want random Web pages to know that they can pipe audio to the remote speakers in my bedroom from my laptop, but if we just expose all the audio output devices, that's exactly what will be possible. Without a much clearer security model, I don't think it's a good idea to add any APIs. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] More effective model for handling resources
On Thu, 13 Mar 2014, Tingan Ho wrote: Almost all web developer I know use externally linked CSS resource in their web projects. That means that the browser needs to (1) request the html page (2) parse the html (3) request for the CSS resource that is linked from the html document. The problem with externally linked resources is point three. It needs to make another request for the CSS resource. There is a solution to this problem and that is to inline the CSS. Though that would yield another problem: all subsequent page request will become bigger. I believe this is being handled by the next-generation transport protocols (SPDY or whatever it's called now). I recommend approaching the relevant groups to check that your precise case has been handled. -- 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 Wed, 19 Mar 2014, Dan Brickley wrote: This is what the example would look like if I'm understanding this right: div itemscope itemtype=http://schema.org/LocalBusiness; h1span itemprop=name(Entity A) Beachwalk Beachwear Giftware/span/h1 span itemprop=description A superb collection of fine gifts and clothing to accent your stay in Mexico Beach./span Phone: span itemprop=telephone850-648-4200/span div itemscope itemtype=http://schema.org/LocalBusiness; itemprop-up=containedIn h2span itemprop=name(Entity B) The tiny store within a store/span/h2 span itemprop=description A superb collection of tiny clothes, from the store within the store./span Phone: span itemprop=telephone123-456-7890/span /div /div It's not too bad, I guess. Yes. I notice that the words we were playing with at schema.org relate to the underlying graph data model itemprop-inverse, -reverse etc., whereas your draft name, itemprop-up is about the markup hierarchy. Yeah. I think most authors think in terms of what they see (their markup), not in terms of the data model. (I have had a _lot_ of conversations with authors where it was clear that they had no idea there was an underlying data model for the microdata that was separate from the markup.) Yup, there are some cases where this can be addressed through the rigorous use of entity IDs in itemid, as you sketch below. That would be relatively new territory for schema.org and for publishers. Perhaps there is an attribute name we can find that would leave the door open to more use cases, e.g. itemprop-backwards rather than itemprop-up. It seems reasonable to try to address relationships between sibling elements too. Well you'd been a new attribute to do that, unless I'm misunderstanding your proposal. Maybe you mean this attribute wouldn't point to a relative place in the markup, but would point to an identified element given by another attribute? I think that would be quite confusing. Something like (trying out -backwards instead of -up, to allow for non-hierarchical usage): div itemid=bigshop itemscope itemtype=http://schema.org/LocalBusiness; h1span itemprop=name(Entity A) Beachwalk Beachwear Giftware/span/h1 /div div itemscope itemtype=http://schema.org/Pharmacy; meta itemprop-backwards=containedIn itemid=bigshop / h2span itemprop=nameTiny pharmacy store within a store/span/h2 /div ? Can we use itemid in that way, to give a property value too? I don't see itemid used much in the wild and the spec only mentions its use for the item having the property, rather than using when supplying the value of a property. itemid= is a URL that gives the identifier of the item. We'd want to use a new attribute to do something like this; e.g.: itemrelation=containedIn bigshop where itemrelation takes just two keywords, a property name and the ID (not itemid) of the target element. But that's pretty elaborate. Is there a need for this? Or is the relationship to the parent all that's needed? In your original e-mail you only suggested wanting to go up. Microdata actually already has a solution to this. The vocabulary can define an ID for each item using itemid=, and can define multiple items having the same ID as being the same conceptual item. Thus: !-- first episode -- div itemscope itemtype=http://schema.org/Episode; ... div itemprop=actor itemscope itemtype=http://schema.org/Person; itemid=http://.../person/123;/div div itemprop=actor itemscope itemtype=http://schema.org/Person; itemid=http://.../person/456;/div /div !-- second episode -- div itemscope itemtype=http://schema.org/Episode; ... div itemprop=actor itemscope itemtype=http://schema.org/Person; itemid=http://.../person/123;/div div itemprop=actor itemscope itemtype=http://schema.org/Person; itemid=http://.../person/456;/div /div !-- actors -- div itemscope itemtype=http://schema.org/Person; itemid=http://.../person/123; ... /div div itemscope itemtype=http://schema.org/Person; itemid=http://.../person/456; ... /div This also enables the data to be spread across multiple pages without confusion. (This is similar to how RDF uses identifiers for everything -- essentially, in RDF terms, this turns the microdata item from a bnode into a node with a global identifier.) Yes, it succeeds or fails to the extent people agree on these global identifiers. Do people not agree on them, typically? Your example would become: div itemscope itemtype=http://schema.org/LocalBusiness; itemid=... h1span itemprop=name(Entity A) Beachwalk Beachwear Giftware/span/h1 span itemprop=description A
Re: [whatwg] Effect on window.opener when navigating an existing window using window.open
On 2 April 2014 18:43, Ian Hickson i...@hixie.ch wrote: On Mon, 3 Mar 2014, Bob Owen wrote: The spec [...] seems to be fairly clear that if an existing window is navigated using window.open, by a browsing context that is not the original opener, then window.opener should remain unchanged. Currently, Trident (and incidentally Presto) seems to have the correct behaviour, but Blink, WebKit and Gecko all change window.opener to the window of the browsing context that has just caused it to navigate. I believe this to be a very long standing difference (10 years for Gecko and Trident) I am proposing to change Gecko to match the spec, but I was advised to raise the issue here before going ahead. Do people agree that window.opener should remain unchanged in this circumstance? Did you receive any off-list feedback on this, or attempt to implement it and get any implementation experience? Thanks for getting back to me Ian. No, no other feedback. I have a patch for it, but haven't pursued it any further. I could investigate putting the change in for Firefox Nightly, if you think that might help with finding any compat issues. Having opener be the actual opener seems pretty intuitive to me; if there's no compat need to do otherwise, it seems like a reasonable choice. Is there a security reason to prefer the latest navigator? Agreed, the specified behaviour makes sense to me, if only because of the name. The fact that you can also use window.open for subsequent navigation (which leads to the different behaviours), muddies the water a bit, but that's a genie that would definitely refuse to go back in the bottle. Over security reasons, although I don't have any concrete examples, I would have thought that either could possibly cause problems, if the opposite behaviour was expected. So, consistency is probably the most important thing. I can also see that both pieces of information (original opener and last navigator) might be useful. So, maybe the other could be added either way.
[whatwg] Various autocomplete= topics
On Wed, 5 Mar 2014, Qebui Nehebkau wrote: On Tue, Mar 4, 2014 at 11:41 PM, Ian Hickson i...@hixie.ch wrote: I think the arguments you've presented so far suggest address-levelN for N=1..4, with 4=region and 3=locality, is probably the simplest thing to do. I was hoping there might be other people with opinions, to give us different perspectives on this, but it seems nobody else cares. :-( Since you asked, I think the whole endeavour (of trying to tokenise an address) is pointless and should be abandoned outright. :) In principle I agree, but in practice I think we have to work with the reality that that is what people are doing. Short of my ideal of *only* offering the full address (as used on a label) as an opaque string, I think it would be most reasonable to consider the 'locality' field itself to be a fully-specified opaque string, including whatever information is necessary to completely identify the location from the region level (such as the prefecture and district), rather than a single level. Failing all that, I would at least prefer for the fields to have names instead of abstract numbering, because people are likely to be confused about the order, no matter which end is the 'widest'. It also seems more intuitive, to me, for the 'locality', as, after all, 'local', to be the most specific level. Would people not be confused by names in the same way? On Wed, 5 Mar 2014, Qebui Nehebkau wrote: Right, impose, certainly not. But, perhaps, (one hopes,) encourage? Or at least refuse to explicitly support anything else. Does autocomplete *need* to support people who are already doing it wrong? But I'm probably just being too utopian; it happens. Well if we don't support pretty much every form out there, the feature isn't particularly useful. On Tue, 4 Mar 2014, Kevin Marks wrote: address-line1 | address-line2 |- street-address address-line3 | address-level4 address-level3 address-level2 / locality address-level1 / region country-name This could work. It has the synonym issue (having multiple fields that mean the same thing is often the source of confusion). Or we could do: address-line1 | address-line2 |- street-address address-line3 | subsublocality sublocality locality region country-name This could work. It avoids the synonym problem. Yes, this alternative works, but in my opinion is not preferable. Because these words don't really mean anything. Nor do numbers. I think we don't really have any chance of giving meaning to the names here either way. On Tue, 4 Mar 2014, Evan Stade wrote: dependent-locality and locality have a fairly precise meaning in the UK. Also in a natural-language conversation, if you ask me what region of the country I live in, I'd say New England, the Midwest, or some such; certainly not the state where I reside. The descriptions for these tokens are currently pretty specific, for example they say a city would be a locality. But this is not true for Beijing or some other cities. To fix the descriptions, we'd have to change them to something like region: the highest level administrative region below country in the address and locality: the second-highest level administrative region below country in the address, sub-locality: the third-highest level administrative region [...]. With you so far. At this point, one wonders why the tokens aren't just [something]1, [something]2, etc. I don't understand how you get there. Why would you wonder this? address-line1 | address-line2 |- street-address address-line3 | locality subsubregion subregion region country-name I don't understand why you think authors will think they need to include subregion, but won't think they need to include address-level3. I think they'll assume subregion returns something for the US if it's sandwiched between region and locality, because county is in between state and city. But in reality, subregion will return nothing. But why does this not apply to the numeric version? Having synonyms is really bad. It leads to huge amounts of confusion. This is why I'm trying to avoid having synonyms for the address-level* stuff. We should definitely not add some just to introduce a slightly better name. My suggestion is to change the address-line1 to street-address-line1, not to have synonyms. Chrome would then support address-line1 for a limited period of time, but outside the spec. There's no outside the spec. The spec tries to describe reality. If you implement something, then that's the reality, and that's what the spec would say, and therefore we'd have
Re: [whatwg] Effect on window.opener when navigating an existing window using window.open
On Wed, 2 Apr 2014, Bob Owen wrote: Did you receive any off-list feedback on this, or attempt to implement it and get any implementation experience? Thanks for getting back to me Ian. No, no other feedback. I have a patch for it, but haven't pursued it any further. I could investigate putting the change in for Firefox Nightly, if you think that might help with finding any compat issues. Well as far as I'm concerned, I would encourage you to try to converge on the spec behaviour. If it turns out there are compatibility issues, that would be good to know. If not, then at least we win more interoperability. I can also see that both pieces of information (original opener and last navigator) might be useful. So, maybe the other could be added either way. I haven't heard any author demand for it, so I haven't added it, but indeed, if this is something authors have a use for, we could add it. It's worth noting that there are many many ways to navigate a browsing context beyond window.open(), e.g. a target=, window.location, drag-and-drop of a link, window.history.go(), etc. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Effect on window.opener when navigating an existing window using window.open
On 2 April 2014 22:00, Ian Hickson i...@hixie.ch wrote: It's worth noting that there are many many ways to navigate a browsing context beyond window.open(), e.g. a target=, window.location, drag-and-drop of a link, window.history.go(), etc. Absolutely, if we were to converge on the spec for the current opener and people felt that last navigator would be useful, then it would need to be updated in all cases. Although, the history case might hold the original state. Anyway, getting way ahead of myself. I'll see if there are any more opinions, then look to move Gecko towards the spec and see if any compat issues arise.
Re: [whatwg] More effective model for handling resources
Hi Ian, I believe this is being handled by the next-generation transport protocols (SPDY or whatever it's called now). I recommend approaching the relevant groups to check that your precise case has been handled. I just found out that SPDY Server Push and Cookies could accomplish the above mentioned caching. Cookies will take care of information providing. And the server just uses Server Push to push content. On Thu, Apr 3, 2014 at 1:57 AM, Ian Hickson i...@hixie.ch wrote: On Thu, 13 Mar 2014, Tingan Ho wrote: Almost all web developer I know use externally linked CSS resource in their web projects. That means that the browser needs to (1) request the html page (2) parse the html (3) request for the CSS resource that is linked from the html document. The problem with externally linked resources is point three. It needs to make another request for the CSS resource. There is a solution to this problem and that is to inline the CSS. Though that would yield another problem: all subsequent page request will become bigger. I believe this is being handled by the next-generation transport protocols (SPDY or whatever it's called now). I recommend approaching the relevant groups to check that your precise case has been handled. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- Sincerely, Tingan Ho
