Re: [whatwg] Should events be paused on detached iframes?
On Tue, 24 Aug 2010, Ben Lerner wrote:
There seems to be a bit of disagreement among browsers about how event
loops and iframes interact when an iframe is removed and then reinserted
into its parent document. Consider the following two documents: the
parent document has a button that removes or reattaches an iframe to the
document, while the second simply sets an interval to update the page
content.
Page1.html:
pbutton onclick=toggleInDoc();Show/hide/button/p
iframe id=test src=page2.html/iframe
script
var test = document.getElementById(test);
function toggleInDoc() {
if (test.parentNode == null)
document.body.appendChild(test);
else
document.body.removeChild(test);
}
/script
Page2.html:
p id=test/p
script
window.setInterval(function() { document.getElementById(test).innerHTML
+= .; }, 500);
/script
Assume the user waits until the interval has fired several times, then
presses the button, waits a while, and presses it again. There are
three possible outcomes:
1. When the iframe is reattached, the inner page reloads. This seems to
go beyond the wording of the spec, which says only When an iframe
element is first inserted into a document, the user agent must create a
nested browsing context, and then process the iframe attributes for the
first time. (This isn't the first time the iframe is inserted into the
document, so we shouldn't process the iframe attributes again.)
Agreed that this contradicts the spec currently.
2. The interval (and presumably, all events) in the iframe is paused
while it's been detached (since the document is no longer fully active,
but it also has not been discarded because of the global reference to
its container element).
The timeout is paused. Events in general aren't necessarily paused; for
example you can synchronously dispatch an event using dispatchEvent() on a
document in an inactive browsing context. Tasks are paused though (so most
events don't fire).
Actually, the spec wasn't really clear about the status of the browsing
context of an iframe that was taken out of a document. I've made the spec
clearer on this matter.
3. The interval (and presumably, all events) continues to fire while
it's been detached, and the content of page2 will have changed while
it's been detached from page1.
That doesn't match the spec.
So far, Chrome 6, Opera 10.6 and Firefox 3.6 follow #1, and IE 8 follows
#3. My reading of the fully active clause of the spec leads me to
expect #2. Which of these behaviors is the desired one? And/or, would
it be desirable to permit authors to specify which behavior they intend?
The spec is #2; it is an attempt to get as close to most existing browsers
as is probably necessary for compatibility, while still allowing the
iframe to be useful (e.g. for the regrafted-iframe trick used by GMail).
On Tue, 24 Aug 2010, Dmitry Titov wrote:
So it seems the right behavior is to keep the content alive. It's not
clear why the events would not fire during DOM operations though.
Perhaps they should, since nothing is changing from the perspective of
the document loaded into iframe - for example, XHR probably should
continue loading content if it was doing so before iframe was
disconnected from its parent node. Doing some suspension (as for example
is done when a page goes into back-forward cache?) would be way more
complex mechanism to have, with necessary events on pause/unpause so the
live document could re-start async operations correctly.
All that currently happens with respect to pausing is that tasks for the
document don't get processed (they remain in the queue). It's actually the
same mechanism that's used for back-forward interactions; per spec,
currently, if you grab a reference (from another Window) to a document
that you then send into session history (bfcache), you can still mutate
that document, call dispatchEvent() on it, run scripts in it, etc. Since
you have a reference to it, it won't get automatically evicted, and when
you traverse the history back to it the changes will be visible (and
queued events and other tasks, e.g. parsing, will start firing again).
The one difference between session history and moving an iframe out of a
document is that with the session history when you send a document into
the back history, it gets unload/pagehide events (and pageshow when it
comes back), whereas the iframe doesn't get any notification at all.
On Tue, 24 Aug 2010, Dirk Pranke wrote:
On a related note, the behavior of onUnload in this situation is quite
unclear. Should onUnload() fire if an iframe is detached from the DOM?
Not per spec.
On Tue, 24 Aug 2010, Dmitry Titov wrote:
At least spec tells that if an iframe is detached from the DOM and then
becomes eligible for GC (not hold via JS reference not DOM connection) -
it gets unloaded w/o onunload firing (4.8.2)
Right. This is
Re: [whatwg] Should events be paused on detached iframes?
On 12/6/10 7:45 PM, Ian Hickson wrote: per spec, currently, if you grab a reference (from another Window) to a document that you then send into session history (bfcache), you can still mutate that document, call dispatchEvent() on it, run scripts in it, etc. I don't believe Gecko would be willing to implement that, for security reasons. As soon as you try to do things of that sort in a bfcached document it _will_ in fact get evicted. I don't believe we plan to change that. I'd be interested in what other UAs views are on this. This is also why we drop the browsing context when an iframe is removed from the document. This part we may be able to change without introducing security problems, maybe... Not clear yet. -Boris
Re: [whatwg] HTML6 Doctype
On Sat, 28 Aug 2010, David John Burrowes wrote: But, I share some of the same concerns (and more) as David Bruant, and would like to understand why this non-versioned HTML is a good thing. I keep imagining long, painful support issues. Non-versioned HTML is the only type of HTML we've had so far, in practice (the version numbers in older drafts of HTML have never had an effect). It's worked for 20 years, why would we change? CSS has some sense of versions (CSS, CSS2, and CSS3). This gives me some ability to say ah, SurfBrowser 1.0 and 2.0 supported CSS1, but with 3.0 they supported some of CSS2 etc etc. Except that that's never true. There has never been a browser, ever, that has supported all of one level of CSS and none of the next level. Same with HTML, the DOM, etc. That is, as long as I'm using the current browser, I know I've got support for whatever is latest. But, when I'm providing support for folks using non-current browsers, there's some value in being able to estimate what will and won't work there. Saying well, I have no idea if our app will work in the browser you have, because no one knows what form of the HTML spec it supported doesn't go over very well with someone paying you money :-). http://caniuse.com/ actually solves this problem. Spec version numbers (whether in documents or just in the spec) do not. Maybe it would make more sense to version the test suite in some fashion? Then one could say: SurfBrowser 7.8 passes the HTML test suite of March 15th, 2012 and so as long as folks know what that test suite is validating, then this might address support issues just fine. You'll never find a useful test suite that coincides exactly with a version of a browser (almost by definition -- a test suite that finds no bugs is almost certainly either incomplete or covers a very narrow scope). On Sun, 29 Aug 2010, David John Burrowes wrote: As I see it, if I'm developing for other major platforms (java, osx, windows, ...) I have a fair degree of certainty which versions of those platforms support what features Sure, because those are single-vendor solutions where the vendor's definition of the platform's version coincides exactly with the vendor's software with the same version. A better parallel is something like C++, where you don't have certainty that the compiler from a particular vendor implementing a particular version of C++ will match the C++ spec exactly, nor that it will match the implementation of another vendor's implementation of the same version, insofar as feature support is concerned (i.e. I'm not just talking about bugs, but about how much of the spec is implemented). On 2010/8/28, at 下午9:09, Jonathan Castello wrote: I would guess that new features would go in their own spec, like Web Workers, WebSockets, and so on. If that is the case, you can still say browser X supports things by naming the specs, e.g. Chrome supports WebSockets. Jonathan, that is certainly true (about the multiple specs). But I think the original question (and, at least, my response to that question) was speaking of just the html spec, and revisions of it, itself. Think about how HTML has been developed in the past 7 years. We've had only one version number. The world has survived fine. Why bother with that version number? It doesn't get us anything useful. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Content-Disposition property for a tags
On Thu, 26 Aug 2010, Roger Hågensen wrote: [..] I navigated to the http://wiki.whatwg.org/wiki/RelExtensions where I found: enclosure described as the destination of the hyperlink is intended to be downloaded and cached and it's marked as proposed currently. And it links further to http://microformats.org/wiki/rel-enclosure which was drafted in the summer of 2005. And it's already in use in the wild (mostly Feed related but by the looks of it elsewhere too). May I suggest adding it to the specs? (after 5 years of proposed status it's kinda time to decide right?) There's work ongoing to decide exactly how the registry for rel= values is going to work; I intend to wait until that is resolved and then letting the appropriate process/community work through the proposed values rather than doing that unilaterally myself. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [br] element should not be a line break
On Thu, 26 Aug 2010, Christoph Päper wrote: Ian Hickson: On Wed, 4 Aug 2010, Thomas Koetter wrote: What strikes me though is that according to the spec The br element represents a line break. A *line* break is presentational in nature. The break is structural, but restricting it to a certain presentation of that break lacks the desired separation of structure and presentation. Wouldn't it make more sense to consider the br element to be just a minor logical break inside a paragraph? Calling it a line break doesn't say how it is rendered. It's just a conceptual description. It presupposes the existance of lines, though. Lines are a very visual concept, although they can be applied to oral language, as in poems and songs (where ‘//’ is often an accepted representation for line breaks in transcripts). An oral line may span several literal lines and vice versa. Right. This is about oral lines (for lack of a better term), not the literal lines. However, I believe the underlying problem is simply that “line break” is (too) often used and understood as a synonym for “new line”, at least by non-native speakers. Speaking of breaks on line or paragraph level therefore makes more sense to me. I don't really understand the difference. (A minor logical break inside a paragraph is not generally represented by a line break, at least not in any typographic conventions I've seen; usually, in my experience, those are denoted either using ellipses, em-dashes, or parentheses.) That’s true for real paragraphs, but not for most “non-paragraphic” texts, e.g. addresses. The lines in an address are separate oral lines, not minor logical breaks inside a pragraph. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Allow Select SVG Elements In head
On Fri, 27 Aug 2010, Hugh Guiney wrote: I'm authoring an XHTML host document with namespaced inline SVG and XLink. I have vector images that recur throughout the site. I'd like to implement SVG's defs and use to reduce the file size of the document and keep style separate from content, as with CSS. If I put an SVG tree with defs anywhere in the XHTML document, other trees with use xlink:href will correctly reference it, as tested in the latest public release Gecko, Webkit, and Opera. So the question becomes, where do I put it? The most obvious answer seems to be head, since, like CSS definitions, this is metadata being defined for use elsewhere in the document. The only problem is, Validator.nu doesn't like it: Error: SVG element svg not allowed as child of XHTML element head in this context. (Suppressing further errors from this subtree.) Same error when ditching the root svg and including only defs, the result of which still works in all but Opera. This error can be avoided if the defs tree is put in the XHTML body, but then there is blank space the size of the defined shapes at the top of the document in all 3 engines. A workaround is to give svg a @width and @height both of 0. But leaving the definitions in the body when they technically don't represent contextual content strikes me as non-semantic. My proposition would be to simply spec a subset of SVG consisting only of metadata elements as valid in HTML's head context. This could be just defs—I'm unsure if there are any other elements that fit this definition since I am relatively new to SVG; but in either case it'd aid semantics and is already supported in today's SVG-capable browsers. This is an interesting idea. I would recommend approaching the SVG working group and suggesting that they define the content model of svg and other SVG elements such that there's two ways to use it: one where svg is considered embedded content, and one where it's considered metadata content, with appropriate restrictions on the latter. With such a set of definitions in place, the HTML spec's model would just work (it already refers to the content model of head as just metadata content, for instance). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Have tabstrip / tab elements been discussed?
On Sat, 28 Aug 2010, E.J. Zufelt wrote: I am rather new to this list and am curious if anytime recently there has been discussion about adding tabstrip and tab elements to the html5 spec? The concept of a tabstrip is a rather commonly used UI component on the web (web-applications, content management systems, facetted searches) and it would be particularly useful for accessibility if we could communicate the semantics of the tabstrip through markup. It has been considered in the past, but on reflection, it seems that tabs are really just a presentational overflow mechanism, rather than a core part of an application or document. For example, there's really no meaningful difference between these two pages, and so you could imagine using alternative style sheets to make the same underlying HTML document render either way: +---+ | .--.___ | using tabs, |_| Food |_Drink_|__| with the two sections | | behind each other. | (o) Pizza| | ( ) Calzone | | | | | +---+ +-+-+ | Food|A| using a scrollbar, | | | with the two sections | (o) Pizza |#| below each other. | ( ) Calzone| | | | | | Drinks | | | -- |V| +-+-+ On Sat, 28 Aug 2010, Tab Atkins Jr. wrote: The semantics of a tab strip is simply several sections with headers. That is, the following: cardstack tabs tabFirst one/tab tabSecond one/tab tabThird one/tab /tabs cards cardI'm the first card/card cardI'm the second card/card cardI'm the third card/card /cards /cardstack ...is semantically equivalent to one or the other of the following: section h1First one/h1 I'm the first card. /section section h1Second one/h1 I'm the second card /section section h1Third one/h1 I'm the third one /section nav ul lia href=#oneFirst one/a/li lia href=#twoSecond one/a/li lia href=#threeThird one/a/li /ul /nav section id=oneI'm the first one/section section id=twoI'm the second one/section section id=threeI'm the third one/section Indeed. On Sat, 28 Aug 2010, E.J. Zufelt wrote: I would disagree with this. There is a meaning in a tabstrip greater than a list of elements. Namely, 1. tabs act within an inferred context (a list item may completely change the context), 2. A single tab is selected (possibly 0 to many, but usually 1). Conceptually, a tab strip is just an overflow mechanism, which section is selected is not a meaningful UI decision beyond the visual. That is, a user should not be worried that opening a different tab is going to change what happens. As such, it's always equivalent to just showing all the tab panels one after each other with a heading. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
