date:20091018

On Fri, 16 Oct 2009, Kornel Lesi�~Dski wrote:
 On 9 Oct 2009, at 09:18, Ian Hickson wrote:
  
  For example, the W3C copy of HTML5 says:
  
h1HTML5/h1
h2A vocabulary and associated APIs for HTML and XHTML/h2
h2Editor's Draft 9 October 2009/h2
...
h2Abstract/h2
 
  ...which is what it would be interpreted as. This is what is meant:
  
section
 h1HTML5;
 A vocabulary and associated APIs for HTML and XHTML;
 Editor's Draft 9 October 2009/h1
 
 If that's what you mean, why not write it this way?
 
h1HTML5
   span class=subtitle
A vocabulary and associated APIs for HTML and XHTMLbr
Editor's Draft 9 October 2009/span/h1

Because HTML5 A vocabulary and associated APIs for HTML and XHTML
Editor's Draft 9 October 2009 is not the title of the document. The title 
is HTML5, and the rest are distinct subtitles. People already use h2 
in this manner, it's a well-established pattern.


 Your version with split h2 seems to use it only for visual effect.

Not just visual, but presentational, yes, pretty much. It also makes it 
clear how to generate the outline.


 I still think that subtitle (subheader, tagline) would be just as 
 effective, less confusing and less likely to break outline when used 
 improperly...

How is h2 confusing? It's what people do already. I think something like 
subtitle is just as likely to be misused as hgroup, to be honest. 
Also, it has a much poorer legacy (backwards compatibility) story.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Workers and addEventListener

On Fri, 16 Oct 2009, Zoltan Herczeg wrote:
 
  I would not be opposed to changing the spec to include enabling a 
  port's message queue when addEventListener(message) is invoked.
 
  I'm reluctant to make addEventListener() do magic.
 
 we have two choices:
   - extend addEventListener
   - fix the Shared Worker example on the whatwg site to call start()
 
 seems the latter one was preferred by the majority of the people. Ian, 
 could you do this fix?

Done! Sorry about that.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] No interface flicker across page loads, without JavaScript

On Fri, 16 Oct 2009, Aryeh Gregor wrote:
 On Thu, Oct 15, 2009 at 3:49 AM, Nelson Menezes
 flying.mushr...@gmail.com wrote:
  As an aside, there is a reason why AJAX has become so popular over the 
  past few years: it solves the specific UI-reset issue that is inherent 
  in full-page refreshes.
 
 I'm trying to think what a solution to this would look like.  Maybe 
 something like:
 
 static id=fooSome stuff that doesn't change on page load.../static
 Changeable page content
 static id=barSome more stuff that doesn't change.../static
 
 The semantics would be that when the browser loaded the new page, it 
 would do something like
 
 1) Retrieve the URL.
 2) Start parsing the new page.  When the time comes to clear the
 screen so it can be redrawn for the new page, leave any static
 elements untouched, so they don't flicker or vanish.
 3) When parsing the page, if a static element is reached that has
 the same id as a static element that was on the old page, ignore the
 contents of the new one.  Instead, move the old static element to
 the position of the new one, copying its DOM.  If possible, this
 shouldn't cause the visible static element to flicker or be redrawn,
 if it's visible.  There should be some reasonable de facto or de jure
 conditions where no-flicker is guaranteed, e.g., all applicable styles
 are the same and the element is absolutely positioned relative to the
 body.
 
 As an added optimization, the browser could send an HTTP request header 
 like Static-IDs containing a list of the IDs of all static elements 
 currently on the page, so that the server can just leave those empty.  
 A dynamic id=foo tag might be useful too, to indicate that specific 
 parts of a static element might indeed change -- in this case the 
 static element might have to be redrawn, but only once the new 
 dynamic element was fully parsed, not before.
 
 I doubt this is suitable for HTML5, given how far along that is, but it 
 might be interesting to consider anyway.  Does the idea sound 
 interesting to anyone else?

It sounds rather scary. :-)

This is definitely something for which I'd be looking towards experimental 
implementations as a guide as to the feasibility, rather than speccing it 
cold. Doing anything with the parsing, especially moving elements from one 
page to another, is very dodgy, especially when you consider what that 
means to the original DOM (which other scripts might still have references 
to, and which might be shown again if the user hits Back).


On Fri, 16 Oct 2009, Markus Ernst wrote:
 
 [...] it introduces some consistency problems to solve, e.g.:

 Page1.html contains:
 
 static id=fooI eat meat/static
 
 and links to page2.html, which contains:
 
 static id=fooI am a vegetarian/static
 
 So page2.html looks different whether it is called from the link in 
 page1.html, or directly via a bookmark, external link, or manual URI 
 input.
 
 This could be solved if static elements have no content on their own, 
 but retrieve it from an external source. The identifyer is then not the 
 id attribute, but the source. This could be done with a src attribute on 
 the static element. But I assume an easier implementation would be 
 adding a static attribute for the iframe element, indicating that 
 the iframe contents should not be reloaded.

Sharing documents across multiple browsing contexts is even more scary -- 
consider what happens to scripts who try to compare the window object.


On Fri, 16 Oct 2009, Aryeh Gregor wrote:
 
 The obvious use case here would just be to keep navigation elements 
 fixed.  For instance, on http://en.wikipedia.org/wiki/, most of div 
 id=column-one could be static.  (With a few exceptions, like div 
 id=p-cactions.)  Navigation tends not to be very interact-able, so 
 reloading it and throwing out client-side changes would be fine if it 
 changes on the server side.

Why can't we just use AJAX, and not reload the page at all, for this?


 A slightly different use-case would be a dynamic application like Gmail, 
 rewritten without AJAX.  The bar on the left contains things like Inbox 
 (2), which are updated by script.  In this case, if new contents were 
 loaded from the server, the server or script would promptly fill in the 
 appropriate numbers and so on.  So again, this use-case doesn't seem to 
 care much if changes are thrown out.

It's not clear to me why GMail would get rid of the AJAXness -- what 
problem would we be solving? Also, with AJAX you can do things like 
transitions, which you couldn't do with page loads.


 Another case to consider is where you have a tree or something that gets 
 uncollapsed depending on what page you're on.  This seems like a case 
 where you'd actually want something slightly different: the new version 
 should load, just without flickering.  Perhaps a cruder solution would 
 be useful, which doesn't affect display of the new page but only how new 
 elements get loaded -- specifically, allowing a mix of content from

Re: [whatwg] a onlyreplace


On Fri, 16 Oct 2009, Aryeh Gregor wrote:
 
 I'm drawn back to my original proposal.  The idea would be as follows: 
 instead of loading the new page in place of the new one, just parse it, 
 extract the bit you want, plug that into the existing DOM, and throw 
 away the rest.  More specifically, suppose we mark the dynamic content 
 instead of the static.
 
 Let's say we add a new attribute to a, like a onlyreplace=foo, 
 where foo is the id of an element on the page.  Or better, a 
 space-separated list of elements.  When the user clicks such a link, the 
 browser should do something like this: change the URL in the navigation 
 bar to the indicated URL, and retrieve the indicated resource and begin 
 to parse it.  Every time an element is encountered that has an id in the 
 onlyreplace list, if there is an element on the current page with that 
 id, remove the existing element and then add the element from the new 
 page.  I guess this should be done in the usual fashion, first appending 
 the element itself and then its children recursively, leaf-first.

On Fri, 16 Oct 2009, Tab Atkins Jr. wrote:
 
 Single-page apps are already becoming common for js-heavy sites.  The 
 obvious example is something like Gmail, but it's becoming more common 
 everywhere.  The main benefit of doing this is that you never dump the 
 script context, so you only have to parse/execute/apply scripting *once* 
 across the page, making really heavy libraries actually usable.

 In fact, writing a single-page app was explicitly given as a suggestion 
 in the Global Script thread.  Even in contexts with lighter scripts, 
 there can still be substantial run-time rewriting of the page which a 
 single-page app can avoid doing multiple times (frex, transforming a 
 nested list into a tree control).
 
 The problem, though, is that single-page apps are currently a bit clunky 
 to write.  They require javascript to function, and the necessary code 
 is relatively large and clunky, even in libraries like jQuery which make 
 the process much simpler.  It requires you to architect your site around 
 the design, either producing a bunch of single-widget files that you 
 query for and slap into place, or some relatively complex client-side 
 logic to parse data structures into HTML.  It's also very hard to get 
 accessibility and graceful degradation right, requiring you to basically 
 completely duplicate everything in a static form.  Finally, preserving 
 bookmarkability/general deeplinking (such as from a search engine) 
 requires significant effort with history management and url hacking.
 
 Aryeh's suggestion, though, solves *all* of these problems with a single 
 trivial attribute.  You first design a static multi-page site like 
 normal, with the only change being this attribute on your navigation 
 links specifying the dynamic/replaceable portions of the page.  In a 
 legacy client, then, you have a perfectly serviceable multipage site, 
 with the only problems being the reloading of js and such on each 
 pageload.
 
 In a supporting client, though, clicking a link causes the browser to 
 perform an ordinary request for the target page (requiring *no* special 
 treatment from the author), parse/treebuild the new page, and then yank 
 out the relevant fragments and replace bits in the current page with 
 them.  The url/history automatically updates properly; bookmarking the 
 page and visiting it later will take you to appropriate static page that 
 already exists.  Script context is maintained, listeners stay around, 
 overall page state remains stable across 'pageloads'.
 
 It's a declarative, accessible, automatic, and EASY way of creating the 
 commonest form of single-page apps.
 
 This brings benefits to more than just the traditional js-heavy apps. My 
 company's web site utilizes jQuery for a lot of small upgrades in the 
 page template (like a hover-expand accordion for the main nav), and for 
 certain things on specific pages.  I know that loading the library, and 
 applying the template-affecting code, slows down my page loads, but it's 
 not significant enough to be worth the enormous effort to create an 
 accessible, search-engine friendly single-page app.  This would solve my 
 problem trivially, though, providing a better overall UI to my visitors 
 (snappier page loads) without any real effort on my part, and without 
 harming accessibility or SEO.
 
 This also trivially replaces most/all uses of bad mechanisms like 
 frameset used to address similar problems (such as maintaining state 
 on a complex nav).
 
 The only addition I'd make to this is to allow a tag in the head that 
 specifies default replaceability for all same-origin links. Perhaps just 
 an attribute on base?  It would accept a space-separated list of ids, 
 just like the @onlyreplace attribute on as.  An @onlyreplace attribute 
 on a link would completely override this default (this would allow me 
 to, frex, have the mainnav only replace the subnav,

Re: [whatwg] object behavior

On Fri, 16 Oct 2009, Ben Laurie wrote:
  On Thu, 6 Aug 2009, Andrew Oakley wrote:
 
  - Should the type attribute take precedence over the Content-Type 
  header?
 
  No, I believe what the spec says here is the preferred behaviour. 
  Unless this is incompatible with legacy content, we should try to move 
  towards this behaviour.
 
 I realise this is only one of dozens of ways that HTML is unfriendly to 
 security, but, well, this seems like a bad idea - if the page thinks it 
 is embedding, say, some flash, it seems like a pretty bad idea to allow 
 the (possibly untrusted) site providing the flash to run whatever it 
 wants in its place.

If the site is untrusted, yet you are letting it run flash, then you've 
lost already. Flash can inject arbitrary JS into your page.

If you are worried about security, I recommend using iframe. The new 
sandbox= feature will help even more, once implemented.


On Fri, 16 Oct 2009, Boris Zbarsky wrote:

 This cuts both ways.  If a site allows me to upload images and I upload 
 an HTML file with some script in it and tell it it's a GIF (e.g. via the 
 name) an then put an object type=text/html 
 data=http://this.other.site/my.gif; on my site...  then I just 
 injected script into a different domain if we let @type override the 
 server-provided header.
 
 This is, imo, a much bigger problem than that of people embedding 
 content from an untrusted site and getting content X instead of content 
 Y, especially because content X can't actually access the page that 
 contains it, right?

Indeed.


On Fri, 16 Oct 2009, Ben Laurie wrote:
 
 The point is that if I think I'm sourcing something safe but it can be 
 overridden by the MIME type, then I have a problem.

If you know it's Flash, use embed. If you know it's an image, use img. 
If you know it's HTML, use iframe. That way you can't get caught like 
this.


On Fri, 16 Oct 2009, Boris Zbarsky wrote:
 
 Perhaps we need an attribute on object that says to only render the 
 data if the server provided type and @type match?  That way you can 
 address your use case by setting that attribute and we don't enable 
 attacks on random servers by allowing @type to override the 
 server-provided type?

Just use one of the more appropriate elements. That way it's safe in older 
UAs also.


On Sat, 17 Oct 2009, Michael A. Puls II wrote:
 On Fri, 16 Oct 2009 05:28:46 -0400, Ian Hickson i...@hixie.ch wrote:
  On Sun, 20 Sep 2009, Michael A. Puls II wrote:
   
   O.K., so put simply, HTML5 should explicitly mention that the css 
   display property for object, embed (and applet in the handling 
   section) has absolutely no effect on plug-in instantiation and 
   destroying and has absolutely no effect on @src and @data resource 
   fetching.
   
   HTML5 could also be extra clear by example that display: none 
   doesn't destroy, or prevent the creation of, the plug-in instance 
   and that changing the display value doesn't destroy the instance.
   
   Lastly, HTML5 could briefly mention that what the plug-in does when 
   its window/area is not displayed because of display: none, is 
   plug-in and plug-in API dependent.
  
  I've added a note to this effect.

 I see the note in the object element section, but don't see it in the 
 embed element section and the applet element section.

Fixed.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] document.documentURI

On Sat, 17 Oct 2009, Darin Fisher wrote:
 On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson i...@hixie.ch wrote:
  On Thu, 15 Oct 2009, Darin Fisher wrote:
  
   This is interesting since documentURI is a read/write property: 
   http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-documentURI
 
  I assume that is a mistake. Does anyone support documentURI? It seems 
  completely redundant with document.URL.

 Gecko and WebKit appear to both support documentURI.  Only WebKit allows it
 to be modified.

On Sat, 17 Oct 2009, Jonas Sicking wrote:
 
 Huh? So WebKit effectively have one of the main features of pushState 
 already? Does the URL-bar change? Does the referrer change for 
 subsequent requests such as navigation? I'm guessing it doesn't hook the 
 back-button the way that pushState does though.

I think this is something for Web DOM Core. I've noted it as an issue on 
the wiki:

   http://wiki.whatwg.org/wiki/Companion_specifications#Specs_to_edit

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Storage events

2009-10-18 Thread Darin Fisher

On Sat, Oct 17, 2009 at 11:58 PM, Jonas Sicking jo...@sicking.cc wrote:

 On Sat, Oct 17, 2009 at 8:37 PM, Darin Fisher da...@chromium.org wrote:
  On Sat, Oct 17, 2009 at 8:20 PM, Ian Hickson i...@hixie.ch wrote:
  ...
 
  On Thu, 15 Oct 2009, Darin Fisher wrote:
  
   This is interesting since documentURI is a read/write property:
   http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-documentURI
 
  I assume that is a mistake. Does anyone support documentURI? It seems
  completely redundant with document.URL.
 
 
  Gecko and WebKit appear to both support documentURI.  Only WebKit allows
 it
  to be modified.

 Huh? So WebKit effectively have one of the main features of pushState
 already? Does the URL-bar change? Does the referrer change for
 subsequent requests such as navigation? I'm guessing it doesn't hook
 the back-button the way that pushState does though.

 / Jonas



It appears to impact the baseURL for the document.

-Darin

Re: [whatwg] a onlyreplace

The cruft in the hash is needed so that we know what IDs to refresh
when navigating back (which could be taken away into a JS URL-to-IDs
map), and to detect a change if the same URL is accessed several times
(that's probably overkill). Still, the point was to show it can work
today; it really isn't an elegant solution as-is :)

Nelson Menezes
http://fittopage.org



2009/10/18 Jonas Sicking jo...@sicking.cc:
 On Sat, Oct 17, 2009 at 12:45 PM, Nelson Menezes
 flying.mushr...@gmail.com wrote:
 2009/10/17 Jonas Sicking jo...@sicking.cc:
 In fact, you don't even need to use pushState. For now this can be
 faked using onhashchange and fragment identifier tricks. It's
 certainly not as elegant as pushState (that is, after all, why
 pushState was added), but it's something that can be tried today.


 Well, here's a badly-hacked-together solution that emulates this behaviour...

 I think it'll be helpful even if it only gets used in a JS library as
 you mention (change the attribute to a classname then). Still, it can
 be made to work with today's browsers:

 http://test.fittopage.org/page1.php

 Yay, sweet! But why so much cruft in the hash? Also, going back to the
 original page (where there is no hash) doesn't seem to work (at least
 in Firefox trunk nightlies).

 / Jonas

Re: [whatwg] object behavior

2009-10-18 Thread Michael A. Puls II


On Mon, 14 Sep 2009 02:10:22 -0400, Ian Hickson i...@hixie.ch wrote:


On Thu, 3 Sep 2009, Michael A. Puls II wrote:

On Wed, 02 Sep 2009 17:39:00 -0400, Ian Hickson i...@hixie.ch wrote:
 On Thu, 27 Aug 2009, Michael A. Puls II wrote:
 
  Here's an example that uses a more modern plug-in that shows what
  browsers do.
 
  window.onload = function() {
  var obj = document.createElement(object);
  obj.type = application/x-shockwave-flash;
  obj.data = http://adobe.com/shockwave/welcome/flash.swf;;
  obj.width = 320;
  obj.height = 240;
  //document.body.appendChild(obj);
  //obj.style.display = none;
  setTimeout(function() {
  alert(obj.SetVariable);
  }, 1000);
  };
 
  In other words, for a plug-in to be initialized (and scriptable if  
it's

  capable):
 
  1. Its element must be attached to the document.

 I'm told this is considered a bug.

O.K., so once that's fixed in browsers, if I do:

var obj = document.createElement(object);
obj.type = application/x-shockwave-flash;
obj.data = file.swf
obj.appendParam(quality, low);

, will that load as soon as I set @type (according to HTML5) and result  
in
@data and the param not being honored because the plug-in already  
initialized?


Hm, good point.

Fixed.


O.K., that requires that the element is in a Document, which is great.  
However, if I use createDocument() to create an HTMLDocument and then  
append an HTMLObjectElement to that document, the plug-in shouldn't load  
as the document is not active/has no browsing context or something.


Is the spec clear that nothing should happen in that case? It seems  
obvious, but want to make sure.


--
Michael

Re: [whatwg] a onlyreplace

2009-10-18 Thread tali garsiel


 dd0fbad0910161343s277083c7v4eee5197c15bd...@mail.gmail.com
Content-Type: text/plain; charset=windows-1255
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


Some comments:

I think an optimization that enables the server to strip unnecessary content is 
a MUST.
It seems the browser will need to make a distinction between a regular request 
and a request invoked by a bookmark.
In case of a bookmark the server should not strip content so the browser must 
let him know that.

In a single page application AJAX updates can be originated in 2 roots:
1. The user clicks something in the navigation panel
2. The user clicks an action button inside the content panel

An example of use case #2 can be clicking a save button.
In this case the a tag is usually not used but a button, this means that 
other tags the  a should have the onlyreplace attribute.
In this example the URL should not be remembered by the history.

There are other cases of use case #2 where the URL should be remembered - like 
a next button on a page-able data grid.

I think this solution is good for changes of the entire content panel.
When a specific widget needs to update a data binding solution may be better.
This means the onlyreplace will probably be always the defaults.









 From: jackalm...@gmail.com
 Date: Fri, 16 Oct 2009 15:43:25 -0500
 To: simetrical+...@gmail.com
 CC: derer...@gmx.ch; wha...@whatwg.org
 Subject: Re: [whatwg] 

 A few public responses to issues/questions brought up in IRC: (thanks,
 Aryeh and Philip!)

 How is this better than  and lt;a targetgt;?lt;br /gt;gt; 
 =lt;br /gt;gt; 
 It's significantly better in multiple ways, actually.lt;br /gt;gt;lt;br 
 /gt;gt; 1. lt;iframegt;s, like frames before them, break bookmarking. If 
 a userlt;br /gt;gt; bookmarks the page and returns to it later, or gets 
 deeplinked via alt;br /gt;gt; search engine or a link from a friend, the 
 lt;iframegt; won't show thelt;br /gt;gt; correct content. The only way 
 around this is some fairly non-triviallt;br /gt;gt; url-hacking with 
 javascript, altering the displayed url as the userlt;br /gt;gt; navigates 
 the iframe, and parsing a deeplink url into an appropriatelt;br /gt;gt; 
 url for the iframe on initial pageload. @onlyreplace, on the otherlt;br 
 /gt;gt; hand, automatically works perfectly with bookmarking. The UA 
 stilllt;br /gt;gt; changes urls and inserts history appropriately as you 
 navigate, and onlt;br /gt
 ;gt; a fresh pageload it just requests the ordinary static page showing 
thelt;br /gt;gt; appropriate content.lt;br /gt;gt;lt;br /gt;gt; 2. 
lt;a targetgt; can only navigate one iframe at a time. Many/mostlt;br 
/gt;gt; sites, though, have multiple dynamic sections scattered throughout 
thelt;br /gt;gt; page. The main site for my company, frex, has 3 
(content,lt;br /gt;gt; breadcrumbs, and section nav) which *cannot* be 
combined to display aslt;br /gt;gt; a single lt;iframegt;, at least not 
without including a whole bunch oflt;br /gt;gt; static content as well. 
You'd have use javascript to hook the linkslt;br /gt;gt; and manually 
navigate the additional iframes. @onlyreplace, on thelt;br /gt;gt; other 
hand, handles this seamlessly - just include multiple ids in thelt;br 
/gt;gt; attribute value.lt;br /gt;gt;lt;br /gt;gt; 3. lt;iframegt;s 
require you to architect your site around them. Ratherlt;br /gt;gt; than a 
series of independen
 t pages, you must create a single masterlt;br /gt;gt; page and then a 
number of content-chunk mini-pages. This breakslt;br /gt;gt; normal 
authoring practices (though in some ways it's easier), andlt;br /gt;gt; 
requires you to work hard to maintain accessibility and such in thelt;br 
/gt;gt; face of these atrophied mini-pages. @onlyreplace works on full,lt;br 
/gt;gt; ordinary pages. It's *possible* to link to a content-chunk 
mini-pagelt;br /gt;gt; instead, but this will spectacularly break if you 
ever deeplinklt;br /gt;gt; straight to one of the pages, so it should become 
automatic forlt;br /gt;gt; authors to do this correctly.lt;br 
/gt;gt;lt;br /gt;gt; 4. lt;iframegt;s have dubious accessibility and 
search effects. I don'tlt;br /gt;gt; know if bots can navigate lt;a 
targetgt; links appropriately. I alsolt;br /gt;gt; believe that this causes 
problems with screen-readers. While eitherlt;br /gt;gt; of these sets of UAs 
can be rewritten 
 to handle lt;iframegt;s better (andlt;br /gt;gt; handle @onlyreplace 
replacement as well), with @onlyreplace theylt;br /gt;gt; *also* have the 
option of just completely ignoring the attribute andlt;br /gt;gt; navigating 
the site as an ordinary multi-page app. Legacy UAs willlt;br /gt;gt; 
automatically do so, providing perfect backwards compatibility.lt;br 
/gt;gt;lt;br /gt;gt;lt;br /gt;gt; Isn't if inefficient to request the 
whole page and then throw most oflt;br /gt;gt; it out? With proper AJAX you 
can just request the bits you

Re: [whatwg] object behavior

2009-10-18 Thread Ben Laurie

On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote:
 On Fri, 16 Oct 2009, Ben Laurie wrote:
  On Thu, 6 Aug 2009, Andrew Oakley wrote:
 
  - Should the type attribute take precedence over the Content-Type
  header?
 
  No, I believe what the spec says here is the preferred behaviour.
  Unless this is incompatible with legacy content, we should try to move
  towards this behaviour.

 I realise this is only one of dozens of ways that HTML is unfriendly to
 security, but, well, this seems like a bad idea - if the page thinks it
 is embedding, say, some flash, it seems like a pretty bad idea to allow
 the (possibly untrusted) site providing the flash to run whatever it
 wants in its place.

 If the site is untrusted, yet you are letting it run flash, then you've
 lost already. Flash can inject arbitrary JS into your page.

Perhaps I am failing to understand, but if I embed anything from an
untrusted site, then it can choose what type it is - so how would I
prevent it running Flash?


 If you are worried about security, I recommend using iframe. The new
 sandbox= feature will help even more, once implemented.

I am worried about security, and I recommend using Caja - but Caja
still has to output valid HTML/CSS/JS...



 On Fri, 16 Oct 2009, Boris Zbarsky wrote:

 This cuts both ways.  If a site allows me to upload images and I upload
 an HTML file with some script in it and tell it it's a GIF (e.g. via the
 name) an then put an object type=text/html
 data=http://this.other.site/my.gif; on my site...  then I just
 injected script into a different domain if we let @type override the
 server-provided header.

 This is, imo, a much bigger problem than that of people embedding
 content from an untrusted site and getting content X instead of content
 Y, especially because content X can't actually access the page that
 contains it, right?

 Indeed.

You just said it could, above.



 On Fri, 16 Oct 2009, Ben Laurie wrote:

 The point is that if I think I'm sourcing something safe but it can be
 overridden by the MIME type, then I have a problem.

 If you know it's Flash, use embed. If you know it's an image, use img.
 If you know it's HTML, use iframe. That way you can't get caught like
 this.


 On Fri, 16 Oct 2009, Boris Zbarsky wrote:

 Perhaps we need an attribute on object that says to only render the
 data if the server provided type and @type match?  That way you can
 address your use case by setting that attribute and we don't enable
 attacks on random servers by allowing @type to override the
 server-provided type?

 Just use one of the more appropriate elements. That way it's safe in older
 UAs also.


 On Sat, 17 Oct 2009, Michael A. Puls II wrote:
 On Fri, 16 Oct 2009 05:28:46 -0400, Ian Hickson i...@hixie.ch wrote:
  On Sun, 20 Sep 2009, Michael A. Puls II wrote:
  
   O.K., so put simply, HTML5 should explicitly mention that the css
   display property for object, embed (and applet in the handling
   section) has absolutely no effect on plug-in instantiation and
   destroying and has absolutely no effect on @src and @data resource
   fetching.
  
   HTML5 could also be extra clear by example that display: none
   doesn't destroy, or prevent the creation of, the plug-in instance
   and that changing the display value doesn't destroy the instance.
  
   Lastly, HTML5 could briefly mention that what the plug-in does when
   its window/area is not displayed because of display: none, is
   plug-in and plug-in API dependent.
 
  I've added a note to this effect.

 I see the note in the object element section, but don't see it in the
 embed element section and the applet element section.

 Fixed.

 --
 Ian Hickson               U+1047E                )\._.,--,'``.    fL
 http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
 Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] object behavior

2009-10-18 Thread Ola P. Kleiven


On Sun, 18 Oct 2009 14:21:56 +0200, Ben Laurie b...@google.com wrote:


On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote:

On Fri, 16 Oct 2009, Ben Laurie wrote:

 On Thu, 6 Aug 2009, Andrew Oakley wrote:

 - Should the type attribute take precedence over the Content-Type
 header?

 No, I believe what the spec says here is the preferred behaviour.
 Unless this is incompatible with legacy content, we should try to  
move

 towards this behaviour.

I realise this is only one of dozens of ways that HTML is unfriendly to
security, but, well, this seems like a bad idea - if the page thinks it
is embedding, say, some flash, it seems like a pretty bad idea to allow
the (possibly untrusted) site providing the flash to run whatever it
wants in its place.


If the site is untrusted, yet you are letting it run flash, then you've
lost already. Flash can inject arbitrary JS into your page.


Perhaps I am failing to understand, but if I embed anything from an
untrusted site, then it can choose what type it is - so how would I
prevent it running Flash?


Running Flash and allowing the same Flash to script your page are two  
different things. Flash needs allowscriptaccess=always to script if it  
is loaded from a different domain. This may not be true for all plug-ins  
though.


--
Ola P. Kleiven, Core Compatibility, Opera Software

Re: [whatwg] hgroup functionality absorbed into header?

2009-10-18 Thread Kornel Lesinski

On Sun, 18 Oct 2009 08:54:59 +0100, Ian Hickson i...@hixie.ch wrote:

Your version with split h2 seems to use it only for visual effect.

Not just visual, but presentational, yes, pretty much. It also makes it
clear how to generate the outline.

I don't understand how presentational h2s make outline clear. I thought
they're an exception that didn't work simple outline algorithm:

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.w3.org%2FTR%2Fhtml5%2Foutline=1#outlineresult

and hgroup exists to resolve ambiguity caused by presentational use of
headers.

I still think that subtitle (subheader, tagline) would be just as
effective, less confusing and less likely to break outline when used
improperly...

How is h2 confusing?

h2 alone isn't. hgroup is the source of confusion.

* Difference between hgroup and header is not obvious. It wasn't to me
when I first saw them, and this isn't first thread about them.
* Makes meaning of hx overloaded (sometimes it's a header that affects
outline and level or other headers, sometimes it's a subheader that
doesn't do anything that header would).

Have you seen this post? http://www.onderhond.com/blog/work/the-hgroup-tag
I think it sums up problems quite well.

I think something like subtitle is just as likely to be misused as
hgroup, to be honest.

Sure, but it's much more fail-safe. If you use header instead of
hgroup or fail to use hgroup, you may significantly change structure
of the document.

You can't make much damage with subheader. Sections will remain correct
and at worst you'll add wrong subtitles to headers.

My proposal for processing of subheader:

* look for first hx preceeding subheader in tree order (depth-first
starting with last child) [makes any subheader after hx work]
* abort and ignore subheader when search crosses section boundaries
[prevents misplaced subheader from being associated with wrong section].

Optionally:
* if hx is an ancestor of subheader, associate subheader with that
header

The last rule allows:

h1subheaderThe magnificent/subheader HTML 5 specification/h1

which addresses one of use cases you've mentioned a while ago when
hgroup was discussed.

Also, it has a much poorer legacy (backwards compatibility) story.

Both solutions have problems. I don't think ones are much worse than the
others. hgroup breaks the outline, subheader is ignored. Without CSS
h2s will be too large and have too big margins. subheader will not get
special rendering, but at least will look like block element (hx and p
typically surrounding it will cause this). One might use psubheaderb
if non-CSS display is a concern.

With CSS subheader will work fine and doesn't limit styling
possibilities. hgroup's content model doesn't allow any non-header
elements, so one can't add any extra hooks for styling:

hgroup
h1/
div!-- add fancy border around subheaders? --
h2/
h2/
/div
/hgroup

Another thing - can you write XPath query that extracts all headers from
the document? Without hgroup it's simple. With hgroup I'm not sure if
I could manage to write correct query.

--
regards, Kornel Lesinski

Re: [whatwg] a onlyreplace

On Sun, Oct 18, 2009 at 4:30 AM, Ian Hickson i...@hixie.ch wrote:
 My recomendation would be to follow the process for adding features:

   
 http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

 In particular the bit about experimental implementations. I think this
 idea looks very interesting, but it's hard to evaluate without concrete
 experience with a browser implementing this (or, as Jonas suggests, a
 library that hacks it in).

 It seems like the kind of thing that we could adopt early on in the next
 feature cycle, if it turns out to be a good solid model.

Yup, was planning on this.  Just wanted to hack it out on the list
first before jumping down any rabbit holes.

If nobody beats me to it, this should be relatively easy to hack in
(and may already be hacked in in some form, via mooTools?).

~TJ

Re: [whatwg] a onlyreplace

2009/10/18 Ian Hickson i...@hixie.ch:

On Sat, 17 Oct 2009, Schuyler Duveen wrote:
One of the big issues we found using it on some other sites is that
javascript listeners (rather than onclick= attributes), and other DOM
pointers in the system became stale. Thus, only half the problem was
solved.

Also, the problem (as I implemented it) is that XMLHttpRequest.xml has
been very finicky in past (and current) browsers. My comments in the
code reflect some of the things you need to make sure you're doing to
make it work across browsers (at least if you want a DOM vs. regex
implementation):

* IE 6 needed the Content-type: text/xml

* Firefox (?2.x) wants xmlns=http://www.w3.org/1999/xhtml; in html tag

* IE and Safari don't handle named entities like nbsp; well in this
context and should be numeric (e.g. #160;)

I ran into the same problem, but it is possible to invoke in current
browsers their HTML parsers by injecting the responseText of
XMLHttpRequest (as opposed to responseXml) into a temporary Document
(in a temp iframe). I would imagine it would be a requirement for
implementing browsers to use the same parsing rules on the
onlyreplace document as they would for a normal document. Indeed, it
should be no harder to build a onlyreplace document than any other,
since the same document would be usable interchangeably in both
contexts.

Vendors might better serve us by reducing these hoops to jump through so
a javascript library could do the job reliably.

This method did make it much easier to leverage server template code.
But since it largely simplifies server template code, then why not stick
with server-side solutions like Ian Bicking's:
http://blog.ianbicking.org/2008/09/08/inverted-partials/

The possibility remains to use partial content responses to optimise
resource usage (via the proposed onlyreplace HTTP header), but the
point of this proposal is that it makes it easy to address the
no-UI-refresh requirement without a complex server- and client-side
framework, and offers transparent fallback. It is not so much that
this can't be done today (it can) but that we would standardise and
promote the way to do it right.

It's still a bit weird that this proposal, instead of allowing every
element to be a link (like XHTML2), would allow every element to be
something like an IFRAME (all while a thread remembering how evil
framesets are continues).

But this doesn't make different elements behave like iframes since
every link still corresponds to a single document, so it doesn't break
navigation or bookmarking.

My recomendation would be to follow the process for adding features:

http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

In particular the bit about experimental implementations. I think this
idea looks very interesting, but it's hard to evaluate without concrete
experience with a browser implementing this (or, as Jonas suggests, a
library that hacks it in).

http://test.fittopage.org/page1.php ?

It seems like the kind of thing that we could adopt early on in the next
feature cycle, if it turns out to be a good solid model.

Is there a mailing list for HTML 6? :-)

[1] http://msdn.microsoft.com/en-us/library/aa155133.aspx
[2] http://developer.yahoo.com/yui/examples/treeview/dynamic_tree.html

Nelson Menezes
http://fittopage.org

Re: [whatwg] a onlyreplace

On Sat, Oct 17, 2009 at 2:45 PM, Nelson Menezes
flying.mushr...@gmail.com wrote:
 2009/10/17 Jonas Sicking jo...@sicking.cc:
 In fact, you don't even need to use pushState. For now this can be
 faked using onhashchange and fragment identifier tricks. It's
 certainly not as elegant as pushState (that is, after all, why
 pushState was added), but it's something that can be tried today.

 Well, here's a badly-hacked-together solution that emulates this behaviour...

 I think it'll be helpful even if it only gets used in a JS library as
 you mention (change the attribute to a classname then). Still, it can
 be made to work with today's browsers:

 http://test.fittopage.org/page1.php

Awesome, Nelson!  Seems to work pretty cool!

I'll hack on it a bit today, see if I can make it a bit more featureful.

~TJ

Re: [whatwg] a onlyreplace

2009/10/18 Nelson Menezes flying.mushr...@gmail.com:
 [1] http://msdn.microsoft.com/en-us/library/aa155133.aspx
 [2] http://developer.yahoo.com/yui/examples/treeview/dynamic_tree.html

Oops, sorry, I meant to give a couple of examples (above) of existing
approaches to maintain user UI state. [1] involves page refresh so it
has the flickering problem, and [2] is custom-built data over AJAX,
which is neither bookmarkable nor easy to implement. You could add
other variants of [2] that are bookmarkable (e.g. Gmail) but all
involve a custom, complex, server-and-client framework. Of course,
there's also framesets/iframes, but that also requires server content
tailored for this interface -- and it breaks bookmarking.

Nelson Menezes
http://fittopage.org

Re: [whatwg] a onlyreplace

On Sun, Oct 18, 2009 at 6:45 AM, tali garsiel t_gars...@hotmail.com wrote:
 Some comments:

 I think an optimization that enables the server to strip unnecessary content 
 is a MUST.

Well, as I explained, it's not really a MUST.  Doing an ordinary
navigation requests an entire page, and without optimizations this
does the exact same thing.  You're not burning *more* bandwidth than
normal; you're just slightly changing the effect of it.

That said, such optimizations would be really useful, I agree.  It
could significantly cut down bandwidth use (on my company's site, the
average request would drop from about 20k to about 1.5k).  This could
*really* improve site performance, and even perhaps be good for the
overall net.

 It seems the browser will need to make a distinction between a regular 
 request and a request invoked by a bookmark.
 In case of a bookmark the server should not strip content so the browser must 
 let him know that.

There's no need to make a distinction.  Only requests with onlyreplace
semantics trigger the special behavior.  Typing an address into your
browser won't add those semantics, nor will a bookmark; only links
with @onlyreplace (or links on a page with base onlyreplace that
don't override their own @onlyreplace with the empty string) carry the
semantics.

If you're talking about this in terms of optimizations, then the
onlyreplace information would be carried by a request header.  When
the browser doesn't send this header, the server wouldn't strip
anything down.

 In a single page application AJAX updates can be originated in 2 roots:
 1. The user clicks something in the navigation panel
 2. The user clicks an action button inside the content panel

 An example of use case #2 can be clicking a save button.
 In this case the a tag is usually not used but a button, this means that 
 other tags the  a should have the onlyreplace attribute.

I thought it would be interesting to be able to put @onlyreplace on
forms, or perhaps form submission inputs.

 In this example the URL should not be remembered by the history.

Then you should use ordinary AJAX to do so.  @onlyreplace is supposed
to be merely an optimization on normal navigation.  The url *must* be
remembered by the history.

 There are other cases of use case #2 where the URL should be remembered - 
 like a next button on a page-able data grid.

Yup, exactly.  A paged control is a great use-case!  It's extremely
simple to set up (just pass paging info in query params), and
bookmarking works beautifully!

 I think this solution is good for changes of the entire content panel.
 When a specific widget needs to update a data binding solution may be better.

Yeah, this is not meant to be a general replacement for AJAX.  It just
makes a particular set of common cases extremely easy.  In many
circumstances being explicit with javascript is still the better
solution.

 This means the onlyreplace will probably be always the defaults.

I'm not sure what you mean here.

~TJ

Re: [whatwg] a onlyreplace

2009/10/18 Tab Atkins Jr. jackalm...@gmail.com:
 On Sun, Oct 18, 2009 at 6:45 AM, tali garsiel t_gars...@hotmail.com wrote:
 It seems the browser will need to make a distinction between a regular 
 request and a request invoked by a bookmark.
 In case of a bookmark the server should not strip content so the browser 
 must let him know that.

 There's no need to make a distinction.  Only requests with onlyreplace
 semantics trigger the special behavior.  Typing an address into your
 browser won't add those semantics, nor will a bookmark; only links
 with @onlyreplace (or links on a page with base onlyreplace that
 don't override their own @onlyreplace with the empty string) carry the
 semantics.

I guess the base @onlyreplace would probably be an important part of
making this truly useful. There might be too many maintainability
problems stemming from having @onlyreplace all over the place on links
(imagine having 5 sections on the page that need updating and dozens
of links... and then adding a 6th section).

 In a single page application AJAX updates can be originated in 2 roots:
 1. The user clicks something in the navigation panel
 2. The user clicks an action button inside the content panel

 An example of use case #2 can be clicking a save button.
 In this case the a tag is usually not used but a button, this means that 
 other tags the  a should have the onlyreplace attribute.

 I thought it would be interesting to be able to put @onlyreplace on
 forms, or perhaps form submission inputs.

The two traditional triggers for navigation are anchors a and form
submissions. The @onlyreplace semantics should not be available
anywhere else since that would be changing the semantics of
non-navigation elements. Any custom UI wizardry should be handled by
Javascript, and the semantics of @onlyreplace would be available via
something like window.location.assignOnlyReplace(url, [ids]);

 In this example the URL should not be remembered by the history.

 Then you should use ordinary AJAX to do so. �...@onlyreplace is supposed
 to be merely an optimization on normal navigation.  The url *must* be
 remembered by the history.

Agreed, as above.

I wonder, though, if there might be a problem with this after all...
picture this:

...
a onlyreplace=div1 div2 href=ingredients.htmlIngredients/a
a onlyreplace=div2 href=nutrition.htmlNutrition/a
a onlyreplace=div3 href=preparation.htmlPreparation/a
...
div id=div1/div
div id=div2/div
div id=div3/div
...

Let's say I click the links in order (Ingredients, Nutrition,
Preparation), and now bookmark the page (it's now preparation.html).
When I return to it, #div1 and #div2 will only be populated if
preparation.html is guaranteed to contain the same content as the
other two documents. There are a lot of testing paths to guarantee
that's the case... does this make the mechanism too fragile?

Nelson Menezes
http://fittopage.org

Re: [whatwg] Storage events

2009-10-18 Thread Adam Barth

On Sun, Oct 18, 2009 at 2:53 AM, Darin Fisher da...@chromium.org wrote:
 On Sat, Oct 17, 2009 at 11:58 PM, Jonas Sicking jo...@sicking.cc wrote:
 On Sat, Oct 17, 2009 at 8:37 PM, Darin Fisher da...@chromium.org wrote:
  Gecko and WebKit appear to both support documentURI.  Only WebKit allows
  it
  to be modified.

 Huh? So WebKit effectively have one of the main features of pushState
 already? Does the URL-bar change? Does the referrer change for
 subsequent requests such as navigation? I'm guessing it doesn't hook
 the back-button the way that pushState does though.

 / Jonas

 It appears to impact the baseURL for the document.

WebKit's behavior of documentURI was my attempt to reconcile the DOM
spec with security and reality.  Previously, WebKit actually let you
assign the internal representation of the documentURI, which was
obviously disaster from a security point of view.

Adam

Re: [whatwg] a onlyreplace

On Sun, Oct 18, 2009 at 10:07 AM, Nelson Menezes
flying.mushr...@gmail.com wrote:
 I guess the base @onlyreplace would probably be an important part of
 making this truly useful. There might be too many maintainability
 problems stemming from having @onlyreplace all over the place on links
 (imagine having 5 sections on the page that need updating and dozens
 of links... and then adding a 6th section).

Yup, my thought exactly.

 I wonder, though, if there might be a problem with this after all...
 picture this:

 ...
 a onlyreplace=div1 div2 href=ingredients.htmlIngredients/a
 a onlyreplace=div2 href=nutrition.htmlNutrition/a
 a onlyreplace=div3 href=preparation.htmlPreparation/a
 ...
 div id=div1/div
 div id=div2/div
 div id=div3/div
 ...

 Let's say I click the links in order (Ingredients, Nutrition,
 Preparation), and now bookmark the page (it's now preparation.html).
 When I return to it, #div1 and #div2 will only be populated if
 preparation.html is guaranteed to contain the same content as the
 other two documents. There are a lot of testing paths to guarantee
 that's the case... does this make the mechanism too fragile?

Ooh, that... is a problem.  I mean, if this is used properly it
shouldn't ever happen, obviously, as every page should be a valid
page.  But the example you described above seems very possible, with
authors thinking that it's okay to create 4 nearly identical pages,
with the sub-pages containing only particular bits filled in (not just
content chunks, but still incomplete).  This degrades badly (just
following each link gives you only partial recipes).  I'd like
bookmarking to return you to something as similar as what you were
looking at before as possible.

The better would be to have only two pages, foo-empty.html and
foo-complete.html, with the links grabbing particular bits from
foo-complete.  Then bookmarking would take you to foo-complete, which
isn't horrible.

Ideally, though, we should never have this situation at all.  Using
@onlyreplace for information hiding is stupid; that's what details
was made for, and it does it *way* better (instantaneous replacement,
no bandwidth waste, bookmarking is fine).

So, hmm.  Is this enough of a problem that we have to address it?  If
it is, probably the best thing to do would be to remove the id list
from a and only leave it on base, with some attribute on links to
indicate whether they should trigger an onlyreplace or a normal
navigation.  That way all links carrying the onlyreplace semantic will
replace the same bits, making the above scenario impossible.

This eliminates many useful cases for onlyreplace, though.  Frex, say
you have a documentation site, with a main-nav up top, a fancy
treeview section-nav on the left, and documentation pages on the
right.  Clicking one of the mainnav links should replace both the
section-nav and the doc page, but clicking on a section-nav link
should only replace the content.  I suppose this is still possible by
just making the main-nav links trigger a normal navigation, the
section-nav links trigger an onlyreplace navigation, and having base
onlyreplace=content.

I feel this may still render onlyreplace unusable for more complex
single-page apps, though.  I dunno, this may be ok - perhaps those
apps are complex enough that we can't meet their needs with a
mechanism this simple anyway.  This limitation wouldn't really hurt
the simpler use-cases that I envisioned (ordinary pages which want to
enhance their static area with heavy js, but don't want the cost of
reloading libraries on every navigation and having things move around
as they get manipulated every time).

Okay, so possible revision: base onlyreplace=foo carries a list of
ids to replace.  This automatically makes all links and forms on the
page carry the onlyreplace semantics.  You can turn this off for
specific links by setting @noreplace (a binary attribute) on the link
or form; activating/submitting them will trigger a normal navigation.

Can anyone think of any concrete cases that were addressed well by the
older suggestion, but are now impossible with this newer revision?
I'm sure there are some, I just want to assess how valuable they may
be before I decide to cut them off.

~TJ

Re: [whatwg] a onlyreplace

Nelson Menezes wrote:
2009/10/18 Ian Hickson i...@hixie.ch:

Well, you are effectively destroying and regenerating parts of your
DOM so whatever JS event handlers you have in place need to be updated
on refresh. That is no different from what happens today with AJAX, or
indeed multi-frame JS.
My point (which feeds on Marcus Ernst's point) is that we need some kind
of load event. Maybe something like:
document.addEventListener('replaceonly')
with the event object providing access to the new DOM content and the
old DOM node.

* IE 6 needed the Content-type: text/xml

* Firefox (?2.x) wants xmlns=http://www.w3.org/1999/xhtml; in html tag

* IE and Safari don't handle named entities like nbsp; well in this
context and should be numeric (e.g. #160;)

Vendors might better serve us by reducing these hoops to jump through so
a javascript library could do the job reliably.

I like this idea a lot. It seems like a job for the HTTP Content-Range
header (using a different word than 'bytes').

One other thought:
It might be a good idea to allow the server to explicitly demand a full
load. (I.e. a server-side equivalent to window.top=location)

There's still seems like a big danger in addressability. Yes, it's a
problem in ajax, but it's a problem that authors can solve on their own
with hash tags (in ad-hoc ways). When the browser takes over the
location value, the author's ability to do that is undermined. Maybe it
should all *stay* in the hash tags like your implementation has it.

Something like:
http://example.com/#id1=page2;id2=page3;
where the value is the most recent source URL for that @id.

cheers,
sky

But this doesn't make different elements behave like iframes since
every link still corresponds to a single document, so it doesn't break
navigation or bookmarking.

My recomendation would be to follow the process for adding features:

http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

http://test.fittopage.org/page1.php ?

It seems like the kind of thing that we could adopt early on in the next
feature cycle, if it turns out to be a good solid model.

Is there a mailing list for HTML 6? :-)

[1] http://msdn.microsoft.com/en-us/library/aa155133.aspx
[2] http://developer.yahoo.com/yui/examples/treeview/dynamic_tree.html

Nelson Menezes
http://fittopage.org

Re: [whatwg] a onlyreplace

2009-10-18 Thread tali garsiel

bay117-w90f5b859cd291ac4e373b83...@phx.gbl

dd0fbad0910180717q60e0c0f5l12e81a337af57...@mail.gmail.com
Content-Type: text/plain; charset=windows-1255
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0

When I said an optimization is a must I didn't just mean bandwidth.
Imagine this use case:
You have a page with a chart and a table showing data calculated from complex
statistical analysis on your huge database.
Both the chart and the table have refresh buttons implemented with a
onlyreplace
Recalculating the chart when you refresh the table or vice verse will not be
acceptable by your project manager :)
The server will need to know what is currently requested.
The solution is not necessarily to strip the content, but the server must get
information of the updated parts and choose what to calculate.

From: jackalm...@gmail.com
Date: Sun, 18 Oct 2009 09:17:19 -0500
Subject: Re: [whatwg]
To: t_gars...@hotmail.com
CC: simetrical+...@gmail.com; derer...@gmx.ch; wha...@whatwg.org

On Sun, Oct 18, 2009 at 6:45 AM, tali garsiel wrote:
Some comments:

I think an optimization that enables the server to strip unnecessary content
is a MUST.

Well, as I explained, it's not really a MUST. Doing an ordinary
navigation requests an entire page, and without optimizations this
does the exact same thing. You're not burning *more* bandwidth than
normal; you're just slightly changing the effect of it.

That said, such optimizations would be really useful, I agree. It
could significantly cut down bandwidth use (on my company's site, the
average request would drop from about 20k to about 1.5k). This could
*really* improve site performance, and even perhaps be good for the
overall net.

It seems the browser will need to make a distinction between a regular
request and a request invoked by a bookmark.
In case of a bookmark the server should not strip content so the browser
must let him know that.

There's no need to make a distinction. Only requests with onlyreplace
semantics trigger the special behavior. Typing an address into your
browser won't add those semantics, nor will a bookmark; only links
with @onlyreplace (or links on a page with that
don't override their own @onlyreplace with the empty string) carry the
semantics.

If you're talking about this in terms of optimizations, then the
onlyreplace information would be carried by a request header. When
the browser doesn't send this header, the server wouldn't strip
anything down.

In a single page application AJAX updates can be originated in 2 roots:
1. The user clicks something in the navigation panel
2. The user clicks an action button inside the content panel

An example of use case #2 can be clicking a save button.
In this case the tag is usually not used but a button, this means that
other tags the should have the onlyreplace attribute.

I thought it would be interesting to be able to put @onlyreplace on
forms, or perhaps form submission inputs.

In this example the URL should not be remembered by the history.

Then you should use ordinary AJAX to do so. @onlyreplace is supposed
to be merely an optimization on normal navigation. The url *must* be
remembered by the history.

There are other cases of use case #2 where the URL should be remembered -
like a next button on a page-able data grid.

Yup, exactly. A paged control is a great use-case! It's extremely
simple to set up (just pass paging info in query params), and
bookmarking works beautifully!

I think this solution is good for changes of the entire content panel.
When a specific widget needs to update a data binding solution may be better.

Yeah, this is not meant to be a general replacement for AJAX. It just
makes a particular set of common cases extremely easy. In many
circumstances being explicit with javascript is still the better
solution.

This means the onlyreplace will probably be always the defaults.

I'm not sure what you mean here.

~TJ

_
Keep your friends updatedeven when youre not signed in.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010

Re: [whatwg] a onlyreplace

On Sun, Oct 18, 2009 at 11:20 AM, Schuyler Duveen
wha...@graffitiweb.org wrote:
 Nelson Menezes wrote:
 2009/10/18 Ian Hickson i...@hixie.ch:

 On Sat, 17 Oct 2009, Schuyler Duveen wrote:
 One of the big issues we found using it on some other sites is that
 javascript listeners (rather than onclick= attributes), and other DOM
 pointers in the system became stale.  Thus, only half the problem was
 solved.

 Well, you are effectively destroying and regenerating parts of your
 DOM so whatever JS event handlers you have in place need to be updated
 on refresh. That is no different from what happens today with AJAX, or
 indeed multi-frame JS.
 My point (which feeds on Marcus Ernst's point) is that we need some kind
 of load event.  Maybe something like:
 document.addEventListener('replaceonly')
 with the event object providing access to the new DOM content and the
 old DOM node.

I agree, though I think it might be better to follow the current
load/unload model with a replaceUnload/replaceLoad event being fired
at the appropriate elements.  (Or, as was suggested by someone else,
just using load/unload on a particular element, since currently it
just fires at window.  I don't know if there are inherent problems
with this or what.)

 The possibility remains to use partial content responses to optimise
 resource usage (via the proposed onlyreplace HTTP header), but the
 point of this proposal is that it makes it easy to address the
 no-UI-refresh requirement without a complex server- and client-side
 framework, and offers transparent fallback. It is not so much that
 this can't be done today (it can) but that we would standardise and
 promote the way to do it right.

 I like this idea a lot.  It seems like a job for the HTTP Content-Range
 header (using a different word than 'bytes').

Yup, something like this should emerge at some point.

 One other thought:
 It might be a good idea to allow the server to explicitly demand a full
 load.  (I.e. a server-side equivalent to window.top=location)

Ah, interesting, a response header that says I know you only asked me
for certain parts of the response, but here's the whole thing instead,
and please load it all.

 There's still seems like a big danger in addressability.  Yes, it's a
 problem in ajax, but it's a problem that authors can solve on their own
 with hash tags (in ad-hoc ways).  When the browser takes over the
 location value, the author's ability to do that is undermined.  Maybe it
 should all *stay* in the hash tags like your implementation has it.

 Something like:
 http://example.com/#id1=page2;id2=page3;
 where the value is the most recent source URL for that @id.

Well, the point is that this should generally act as just an
optimization of normal navigation.  Clicking on a href=foo
onlyreplace=bar should give you the same result as clicking on a
href=foo, just without the overall page getting flushed.  So the
address should update to http://example.com/foo;, etc.

You can always url-hack on your own, if you need to.

~TJ

Re: [whatwg] a onlyreplace

On Sun, Oct 18, 2009 at 11:22 AM, tali garsiel t_gars...@hotmail.com wrote:
 When I said an optimization is a must I didn't just mean bandwidth.
 Imagine this use case:
 You have a page with a chart and a table showing data calculated from complex 
 statistical analysis on your huge database.
 Both the chart and the table have refresh buttons implemented with a 
 onlyreplace 
 Recalculating the chart when you refresh the table or vice verse will not be 
 acceptable by your project manager :)
 The server will need to know what is currently requested.
 The solution is not necessarily to strip the content, but the server must get 
 information of the updated parts and choose what to calculate.

That's not really an appropriate use of @onlyreplace.  Just put the
chart and table in iframes with @name and use a target to refresh
them.  That also automatically optimizes bandwidth, since the subpages
that the chart and frame will live on contain *only* them.

(Preventing this sort of abuse might be a good reason to do the only
base can carry an id list revision.)

~TJ

Re: [whatwg] a onlyreplace

2009-10-18 Thread Scott González

On Sun, Oct 18, 2009 at 12:28 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:

 Well, the point is that this should generally act as just an
 optimization of normal navigation.  Clicking on a href=foo
 onlyreplace=bar should give you the same result as clicking on a
 href=foo, just without the overall page getting flushed.  So the
 address should update to http://example.com/foo;, etc.


I've only been partially following this thread, so this may have been
answered previously. Is this an accurate summary of what you're thinking of?

Clicking a href=foo and a href=foo onlyreplace=bar would send the
exact same headers to the server with the exception of a single extra header
for the @onlyreplace version?

In the case of @onlyreplace, would the #bar element end up being replaced,
or just its content? Would the server be expected to reply with div
id=bar.../dv or just what would would become bar.innerHTML?

Re: [whatwg] a onlyreplace

2009/10/18 Scott González scott.gonza...@gmail.com:
 On Sun, Oct 18, 2009 at 12:28 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:

 Well, the point is that this should generally act as just an
 optimization of normal navigation.  Clicking on a href=foo
 onlyreplace=bar should give you the same result as clicking on a
 href=foo, just without the overall page getting flushed.  So the
 address should update to http://example.com/foo;, etc.

 I've only been partially following this thread, so this may have been 
 answered previously. Is this an accurate summary of what you're thinking of?

 Clicking a href=foo and a href=foo onlyreplace=bar would send the 
 exact same headers to the server with the exception of a single extra header 
 for the @onlyreplace version?

Yes.

 In the case of @onlyreplace, would the #bar element end up being replaced, or 
 just its content?

The full element.

 Would the server be expected to reply with div id=bar.../dv or just 
 what would would become bar.innerHTML?

The former.  As well, the server *can* return the whole document, but
is only required to send the requested elements.

~TJ

Re: [whatwg] a onlyreplace

Tab Atkins Jr. wrote:
 On Sun, Oct 18, 2009 at 11:20 AM, Schuyler Duveen
 wha...@graffitiweb.org wrote:
 Nelson Menezes wrote:
 My point (which feeds on Marcus Ernst's point) is that we need some kind
 of load event.  Maybe something like:
 document.addEventListener('replaceonly')
 with the event object providing access to the new DOM content and the
 old DOM node.
 
 I agree, though I think it might be better to follow the current
 load/unload model with a replaceUnload/replaceLoad event being fired
 at the appropriate elements.  (Or, as was suggested by someone else,
 just using load/unload on a particular element, since currently it
 just fires at window.  I don't know if there are inherent problems
 with this or what.)
I like the first one.  I'd rather it be on the document (or window) so
we don't have to wait for the first instance of an element to show up.

More importantly, then I can write javascript that's more generic rather
having to know about which specific elements will be doing the
loading/unloading in a particular document.

 There's still seems like a big danger in addressability.  Yes, it's a
 problem in ajax, but it's a problem that authors can solve on their own
 with hash tags (in ad-hoc ways).  When the browser takes over the
 location value, the author's ability to do that is undermined.  Maybe it
 should all *stay* in the hash tags like your implementation has it.

 Something like:
 http://example.com/#id1=page2;id2=page3;
 where the value is the most recent source URL for that @id.
 
 Well, the point is that this should generally act as just an
 optimization of normal navigation.  Clicking on a href=foo
 onlyreplace=bar should give you the same result as clicking on a
 href=foo, just without the overall page getting flushed.  So the
 address should update to http://example.com/foo;, etc.
 
 You can always url-hack on your own, if you need to.
The problem is that people will make links that refresh different parts
of a document, to the point that the current document is no longer
addressable.  Use cases for this happen often enough (not necessarily
good design, but people will do this)

In the past, a good way to give (back) addressability to users is with
hash tags.  But here, the location changes, and the hash goes away.
Standard anchor tags (with no javascript) have generally been
addressable to users by default.  When this hasn't been true, like with
framesets, lots of confusion and frustration ensues.

If this is, in the longterm, going to work non-dynamically, then things
should be addressable by default.  It's one of the killer features of
the web :-)

/skjy

 
 ~TJ

Re: [whatwg] a onlyreplace

On Sun, Oct 18, 2009 at 11:50 AM, Schuyler Duveen
wha...@graffitiweb.org wrote:
 Tab Atkins Jr. wrote:
 On Sun, Oct 18, 2009 at 11:20 AM, Schuyler Duveen
 wha...@graffitiweb.org wrote:
 Nelson Menezes wrote:
 My point (which feeds on Marcus Ernst's point) is that we need some kind
 of load event.  Maybe something like:
 document.addEventListener('replaceonly')
 with the event object providing access to the new DOM content and the
 old DOM node.

 I agree, though I think it might be better to follow the current
 load/unload model with a replaceUnload/replaceLoad event being fired
 at the appropriate elements.  (Or, as was suggested by someone else,
 just using load/unload on a particular element, since currently it
 just fires at window.  I don't know if there are inherent problems
 with this or what.)
 I like the first one.  I'd rather it be on the document (or window) so
 we don't have to wait for the first instance of an element to show up.

 More importantly, then I can write javascript that's more generic rather
 having to know about which specific elements will be doing the
 loading/unloading in a particular document.

As long as the event bubbles, you can always just listen at the
document root and then check event.target to see who got updated.
That way you don't have to wait, nor do you have to know which
specific bits are getting replaced.

 There's still seems like a big danger in addressability.  Yes, it's a
 problem in ajax, but it's a problem that authors can solve on their own
 with hash tags (in ad-hoc ways).  When the browser takes over the
 location value, the author's ability to do that is undermined.  Maybe it
 should all *stay* in the hash tags like your implementation has it.

 Something like:
 http://example.com/#id1=page2;id2=page3;
 where the value is the most recent source URL for that @id.

 Well, the point is that this should generally act as just an
 optimization of normal navigation.  Clicking on a href=foo
 onlyreplace=bar should give you the same result as clicking on a
 href=foo, just without the overall page getting flushed.  So the
 address should update to http://example.com/foo;, etc.

 You can always url-hack on your own, if you need to.
 The problem is that people will make links that refresh different parts
 of a document, to the point that the current document is no longer
 addressable.  Use cases for this happen often enough (not necessarily
 good design, but people will do this)

 In the past, a good way to give (back) addressability to users is with
 hash tags.  But here, the location changes, and the hash goes away.
 Standard anchor tags (with no javascript) have generally been
 addressable to users by default.  When this hasn't been true, like with
 framesets, lots of confusion and frustration ensues.

 If this is, in the longterm, going to work non-dynamically, then things
 should be addressable by default.  It's one of the killer features of
 the web :-)

You're right, and this makes me think more strongly that restricting
the ability to specify the replaceable bits to just base is the
right way to do this.

~TJ

Re: [whatwg] a onlyreplace

2009-10-18 Thread tali garsiel


dd0fbad0910180717q60e0c0f5l12e81a337af57...@mail.gmail.com 

bay117-w9daba5e3a74376fb4bbfc83...@phx.gbl
 

 dd0fbad0910180935i6b07e025t14f4cc5aaacb3...@mail.gmail.com
Content-Type: text/plain; charset=windows-1255
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0


I'll try to fix my example.
The table button is not refresh but a next button that keeps track of the 
table navigation.

That is a valid use case , isn't it? (at least by your first suggestion). You 
still wouldn't want the server to do any heavy calculation except for the data 
that needs to be displayed.

I tried to find an extreme use case but even showing the navigation panels 
often evolves lots of server work.
Examples can be license and permission checks for an entire tree and parsing 
xml files containing tab contents.
Some of this work can be avoided by using session caching but some is not, 
mainly security checks.



 From: jackalm...@gmail.com
 Date: Sun, 18 Oct 2009 11:35:11 -0500
 Subject: Re: [whatwg] 
 To: t_gars...@hotmail.com
 CC: derer...@gmx.ch; simetrical+...@gmail.com; wha...@whatwg.org

 On Sun, Oct 18, 2009 at 11:22 AM, tali garsiel  wrote:
 When I said an optimization is a must I didn't just mean bandwidth.
 Imagine this use case:
 You have a page with a chart and a table showing data calculated from 
 complex statistical analysis on your huge database.
 Both the chart and the table have refresh buttons implemented with .
 Recalculating the chart when you refresh the table or vice verse will not be 
 acceptable by your project manager :)
 The server will need to know what is currently requested.
 The solution is not necessarily to strip the content, but the server must 
 get information of the updated parts and choose what to calculate.

 That's not really an appropriate use of @onlyreplace. Just put the
 chart and table in s with @name and use lt;a targetgt; to refreshlt;br 
 /gt;gt; them. That also automatically optimizes bandwidth, since the 
 subpageslt;br /gt;gt; that the chart and frame will live on contain *only* 
 them.lt;br /gt;gt;lt;br /gt;gt; (Preventing this sort of abuse might be 
 a good reason to do the onlylt;br /gt;gt; lt;basegt; can carry an id 
 list revision.)lt;br /gt;gt;lt;br /gt;gt; ~TJlt;br /gt;  
   
_
Keep your friends updatedeven when youre not signed in.
http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_5:092010

Re: [whatwg] a onlyreplace

2009/10/18 Tab Atkins Jr. jackalm...@gmail.com:
 As long as the event bubbles, you can always just listen at the
 document root and then check event.target to see who got updated.
 That way you don't have to wait, nor do you have to know which
 specific bits are getting replaced.

You would want the event to fire once, though, regardless of how many
targets are being replaced. Otherwise you won't be able to distinguish
3 events generated by one response with content for #div1,#div2, and
#div3. Event.target should be the original a or form element, or
the window object if the request originated via scripting.

Nelson Menezes
http://fittopage.org

Re: [whatwg] a onlyreplace

On Sun, Oct 18, 2009 at 12:20 PM, Nelson Menezes
flying.mushr...@gmail.com wrote:
 2009/10/18 Tab Atkins Jr. jackalm...@gmail.com:
 As long as the event bubbles, you can always just listen at the
 document root and then check event.target to see who got updated.
 That way you don't have to wait, nor do you have to know which
 specific bits are getting replaced.

 You would want the event to fire once, though, regardless of how many
 targets are being replaced. Otherwise you won't be able to distinguish
 3 events generated by one response with content for #div1,#div2, and
 #div3. Event.target should be the original a or form element, or
 the window object if the request originated via scripting.

My thoughts were that the event fires at the replaced elements, not
the a or form that triggered the navigation.  So you *would* be
able to distinguish multiple elements, as their event.target would
point to each element as appropriate.

This isn't a click or whatever event, it's a load/unload event.  The
a or form isn't doing either.

~TJ

Re: [whatwg] a onlyreplace

2009-10-18 Thread Aryeh Gregor

On Sat, Oct 17, 2009 at 1:22 AM, Jonas Sicking jo...@sicking.cc wrote:
 Also, what should happen if the user presses the 'back' button?

It should be the same as for regular navigation.  If the UA usually
stores some page state in a cache when the user navigates, it should
store the same state.  If it doesn't have the previous contents cache,
it should reload, assuming that's what it normally does.

On Sun, Oct 18, 2009 at 11:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 Okay, so possible revision: base onlyreplace=foo carries a list of
 ids to replace.  This automatically makes all links and forms on the
 page carry the onlyreplace semantics.  You can turn this off for
 specific links by setting @noreplace (a binary attribute) on the link
 or form; activating/submitting them will trigger a normal navigation.

By all links and forms do you really mean all same-domain links and
forms?  Even that's too many.  Consider a typical site with a forum
at /forum and a wiki at /wiki.  You don't want links from one to the
other to try onlyreplacing.  Even within an app it can be complicated.
 MediaWiki is often installed in both /w (actual files) and /wiki
(fake rewrite path), and you'd probably want links to everything in
/wiki but only some things in /w to be affected.

Perhaps a onlyreplace should be a boolean attribute.  Opting links
into onlyreplace seems safer than opting them out.  In many cases you
might be injecting some raw HTML into the page, like using a template
system or JavaScript, such that adding noreplace to all links you're
unsure about would be tricky or impossible.  Opt-in is much easier to
verify.

In any event, this variant is fairly disastrous for copy-pasting.
What you thought meant load only foo and bar from the target might
suddenly mean load only baz and quuz from the target, and the result
will probably be that the link completely fails.  I think sticking
only to per-a attributes is a safer idea, one way or another.

Also, I anticipate that on many pages that would like to use this
feature, only some unpredictable minority of links would actually need
it.  I don't think there will be any way to identify which ones
without some kind of case-by-case human intervention, so I don't think
base would be terribly useful.


Some attention needs to be given to error handling.  What happens if
one or more of the requested id's aren't found?  Do they silently
fail?  If so, this could result in the link doing absolutely nothing
in hard-to-control situations -- like an error page that occurs
sporadically, say a 500.  Do they trigger a normal page load?  If so,
they have to wait until the entire page has loaded, which would be bad
user experience but hard to track down -- a long, inexplicable delay
followed by everything working normally.  This could be mitigated by
having an HTTP header to say that id doesn't exist, load the whole
page instead, but it would fail in the default case (standard HTTP
server unaware of new feature).

Also, what happens if some of the given id's are present, but not others?


One final observation is that this method isn't ideal for fixing
flickering, because often you'll want to change everything at once --
you just don't want it to flicker.  For instance, consider a case
where you have a navigation pane and a content pane.  Changing pages
will change the content pane, but also sometimes cause a different
item to be highlighted in the navigation pane, or cause some
contextual items to disappear and reappear, etc.  However, a solution
to that has all the advantages of the onlyreplace proposal, that's
simple to describe using existing functionality, and works well with
URLs, but doesn't kill all script handlers and such, seems hard.

On Sun, Oct 18, 2009 at 12:22 PM, tali garsiel t_gars...@hotmail.com wrote:
 Imagine this use case:
 You have a page with a chart and a table showing data calculated from complex 
 statistical analysis on your huge database.
 Both the chart and the table have refresh buttons implemented with a 
 onlyreplace 
 Recalculating the chart when you refresh the table or vice verse will not be 
 acceptable by your project manager :)

I don't think the scenario is realistic.  You can't usually get away
with calculating anything very expensive on page load, because then
page load would take unacceptably long.  Calculations like this that
you want to run as infrequently as possible are normally cached on the
server side, in my experience.  If they weren't you'd re-run the
calculations every time the user navigates away and then back, or
reloads the page.  I don't see why that would be acceptable if the
behavior you describe isn't.

Re: [whatwg] a onlyreplace

On Sun, Oct 18, 2009 at 12:25 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
 On Sun, Oct 18, 2009 at 11:51 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 Okay, so possible revision: base onlyreplace=foo carries a list of
 ids to replace.  This automatically makes all links and forms on the
 page carry the onlyreplace semantics.  You can turn this off for
 specific links by setting @noreplace (a binary attribute) on the link
 or form; activating/submitting them will trigger a normal navigation.

 By all links and forms do you really mean all same-domain links and
 forms?

Yes.

 Even that's too many.  Consider a typical site with a forum
 at /forum and a wiki at /wiki.  You don't want links from one to the
 other to try onlyreplacing.  Even within an app it can be complicated.
  MediaWiki is often installed in both /w (actual files) and /wiki
 (fake rewrite path), and you'd probably want links to everything in
 /wiki but only some things in /w to be affected.

 Perhaps a onlyreplace should be a boolean attribute.  Opting links
 into onlyreplace seems safer than opting them out.  In many cases you
 might be injecting some raw HTML into the page, like using a template
 system or JavaScript, such that adding noreplace to all links you're
 unsure about would be tricky or impossible.  Opt-in is much easier to
 verify.

I think the opposite.  If I upgraded my site to this, I'd want nearly
all the links to onlyreplace.  There's only a handful of same-origin
links that I'd instead want to trigger a full load.

 In any event, this variant is fairly disastrous for copy-pasting.
 What you thought meant load only foo and bar from the target might
 suddenly mean load only baz and quuz from the target, and the result
 will probably be that the link completely fails.  I think sticking
 only to per-a attributes is a safer idea, one way or another.

It's true that this could be bad on copypasta, but is your failure
scenario going to be common?  Are people going to often use different
bases on different pages in the same origin?  I think more usually a
single origin will have the same base onlyreplace everywhere, or
else not have base onlyreplace at all.  In the latter case, you'd
presumably want all links to trigger full navigation, since that's
what you're indicating with the lack.

(Also, the same problem you note happens similarly with per-a
onlyreplace - what if you copy a link from one page to another, and
the new page has *different* elements with the same #ids as elements
in the old page?  Then you'd be replacing random bits of the page.  Is
this situation more/less likely than the one you brought up?)

 Also, I anticipate that on many pages that would like to use this
 feature, only some unpredictable minority of links would actually need
 it.  I don't think there will be any way to identify which ones
 without some kind of case-by-case human intervention, so I don't think
 base would be terribly useful.

I disagree, and think that most links would use it on a typical page.

 Some attention needs to be given to error handling.  What happens if
 one or more of the requested id's aren't found?  Do they silently
 fail?  If so, this could result in the link doing absolutely nothing
 in hard-to-control situations -- like an error page that occurs
 sporadically, say a 500.  Do they trigger a normal page load?  If so,
 they have to wait until the entire page has loaded, which would be bad
 user experience but hard to track down -- a long, inexplicable delay
 followed by everything working normally.  This could be mitigated by
 having an HTTP header to say that id doesn't exist, load the whole
 page instead, but it would fail in the default case (standard HTTP
 server unaware of new feature).

 Also, what happens if some of the given id's are present, but not others?

I'll think a bit about these issues today.  I'm not sure, off the top
of my head, what the best response is.

 One final observation is that this method isn't ideal for fixing
 flickering, because often you'll want to change everything at once --
 you just don't want it to flicker.  For instance, consider a case
 where you have a navigation pane and a content pane.  Changing pages
 will change the content pane, but also sometimes cause a different
 item to be highlighted in the navigation pane, or cause some
 contextual items to disappear and reappear, etc.  However, a solution
 to that has all the advantages of the onlyreplace proposal, that's
 simple to describe using existing functionality, and works well with
 URLs, but doesn't kill all script handlers and such, seems hard.

You'd just hook the links with javascript and use that to change the
navigation-pane highlight.  (Or, in some cases, harness CSS, such as
by using the proposed pseudoclass that matches links to the current
document.)

~TJ

Re: [whatwg] No interface flicker across page loads, without JavaScript

2009-10-18 Thread Aryeh Gregor

On Sun, Oct 18, 2009 at 5:19 AM, Ian Hickson i...@hixie.ch wrote:
 Why can't we just use AJAX, and not reload the page at all, for this?

1) AJAX is more difficult to set up, as far as I understand it.  I
can't say for sure, since I haven't ever tried to set up AJAX from
scratch.

2) Getting bookmarkable/sharable URLs right requires extra effort with
AJAX.  Without HTML5 scripted history traversal (pushState, etc., IIRC
-- I haven't looked at that yet, you know what I mean), it's not even
possible to do it in a way that interoperates with non-JS UAs, like
search engines following links that users have posted to forums.  You
have to store state in hashes, and reconstruct it using JS.

3) Getting fallback to non-JS UAs right requires you to write
everything twice, pretty much.  Or create a complicated framework that
will automatically generate everything twice.  In particular, search
engines don't work well with AJAX at all.

All I can say is that in practice, I've never even bothered looking at
AJAX for page-reload situations (as opposed to performing actions
within the current page) because it seems too complicated to do right.
 A simple method that would automatically fall back to full page
retrieval would be much more attractive to me.

 It's not clear to me why GMail would get rid of the AJAXness -- what
 problem would we be solving? Also, with AJAX you can do things like
 transitions, which you couldn't do with page loads.

I don't think Gmail specifically would get rid of AJAX.  The feature
described here is only useful for simple cases.  It's not clear to me
at this point whether it's a good enough tradeoff between simplicity
and power to get significant uptake at all, let alone in sites with
much more complicated needs.

 On Fri, 16 Oct 2009, Aryeh Gregor wrote:

 So, here's a preliminary description of a use-case.  I'm not sure it's
 sane yet.

 Use Case: A page should be able to instruct that when a user follows a
 link, only part of the page is reloaded, while the rest stays fixed.

 That's not a use case, it's a feature description. The use case is the
 _why_ -- what is the problem being solved?

I'm not *entirely* sure, since I've never seen the need to use
anything like this myself.  The desired features seem to include:

a) Avoiding flickering and jumping on page load.
b) Saving bandwidth.
c) Being able to preserve state of some parts of the page (e.g.,
navigation collapse state) when others change (e.g., new content
loaded).

Is the desirability of those three things clear enough for them to
qualify as use cases?  I don't know if the list is exhaustive.

(a) seems to have some people (at least Tab) interested in the feature
proposal for its sake alone.  It's possible that (a) could best be
solved by general adjustments to how browsers lay out pages, perhaps
opt-in, but that's way beyond my field of expertise.  The basic
problem seems to be that on the one hand, browsers need to do
progressive rendering so that the page is usable as quickly as
possible; but on the other hand, this means they need to clear away
the whole page, including parts that won't actually change.  Some way
of hinting that certain parts shouldn't be cleared away, or should be
cleared away in a different manner, but *without* changing what will
show up when the page is finally loaded, might be a better solution
here.  It might affect only presentation and be invisible even to
scripts.

(b) is probably the least important of the three features, and can be
addressed by other means that might be more useful overall (like
SDCH).  Some of the proposals have incidentally included some features
in this direction because they seemed simple to tack on.

(c) looks like the part that really needs to be solved by something
along the lines of the given proposals, if AJAX and frames (and saving
state in cookies and recreating it on page load, etc.) are
unacceptable for whatever reason.  Frames have problems that are very
well recognized.  AJAX has at least the problems mentioned above.
Saving and recreating state on page load is a pain, I guess, and it
would be nicer if it were automatic.

I'm not the best person to ask here, though.  All I can say personally
is that if a good, robust mechanism were developed along the lines I
and others have described, that doesn't create the potential for scary
random errors of various stripes, then I *might* use it.  I wrote my
proposal based on the discussion about frames -- use AJAX didn't
seem acceptable to a lot of people in the discussion, for whatever
reason.  I'm not personally all that interested in this feature.

Re: [whatwg] a onlyreplace

2009-10-18 Thread Aryeh Gregor

On Sun, Oct 18, 2009 at 1:37 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 I think the opposite.  If I upgraded my site to this, I'd want nearly
 all the links to onlyreplace.  There's only a handful of same-origin
 links that I'd instead want to trigger a full load.

It's very common for several web apps to be installed under a single
domain, with links from one to the others: the wiki, forum, and CMS
all linking to each other, say.  These links are often added to
templates by admins as static HTML that the app doesn't even look at.
Having them break horribly when the next version of the software uses
onlyreplace isn't helpful.  Basically, if you're outputting *any* HTML
without parsing and sanitizing it, opt-out isn't acceptable, since you
*can't* opt out of links in that HTML.  And every web app I'm familiar
with (admittedly that's about two) does output some HTML without
parsing and sanitizing it.

Keep in mind that if you can't opt out when you need to, the link will
fail.  If you can't opt in when you need to, the link will work, just
trigger a full reload.  Opt-in is a much better idea for that reason
alone, given that many apps won't be able to sanitize some of the
links they output.

 It's true that this could be bad on copypasta, but is your failure
 scenario going to be common?  Are people going to often use different
 bases on different pages in the same origin?  I think more usually a
 single origin will have the same base onlyreplace everywhere, or
 else not have base onlyreplace at all.  In the latter case, you'd
 presumably want all links to trigger full navigation, since that's
 what you're indicating with the lack.

I didn't remember that it would only be same-domain.  You're right
that that's a mitigation.  But yes, I'd very much expect the same
domain to often use different onlyreplace.  Different web apps will
have different onlyreplaces, and different web apps are often on the
same domain.

 (Also, the same problem you note happens similarly with per-a
 onlyreplace - what if you copy a link from one page to another, and
 the new page has *different* elements with the same #ids as elements
 in the old page?  Then you'd be replacing random bits of the page.  Is
 this situation more/less likely than the one you brought up?)

I'd hope id collision would be rare enough that this isn't a huge
issue.  MediaWiki tries to prefix all new classes and id's with mw-
for this sort of reason.  id's like content are likely to show up
pretty often, though, you're right.  (And in fact MediaWiki does have
an id=content in the default skin.)

 I disagree, and think that most links would use it on a typical page.

I'm not sure anymore.  It depends how it's used.

 You'd just hook the links with javascript and use that to change the
 navigation-pane highlight.  (Or, in some cases, harness CSS, such as
 by using the proposed pseudoclass that matches links to the current
 document.)

Well, okay.  That completely defeats the ease of use of this proposal, though.

Re: [whatwg] a onlyreplace

2009/10/18 Tab Atkins Jr. jackalm...@gmail.com:
 On Sun, Oct 18, 2009 at 12:20 PM, Nelson Menezes
 flying.mushr...@gmail.com wrote:
 2009/10/18 Tab Atkins Jr. jackalm...@gmail.com:
 As long as the event bubbles, you can always just listen at the
 document root and then check event.target to see who got updated.
 That way you don't have to wait, nor do you have to know which
 specific bits are getting replaced.

 You would want the event to fire once, though, regardless of how many
 targets are being replaced. Otherwise you won't be able to distinguish
 3 events generated by one response with content for #div1,#div2, and
 #div3. Event.target should be the original a or form element, or
 the window object if the request originated via scripting.

 My thoughts were that the event fires at the replaced elements, not
 the a or form that triggered the navigation.  So you *would* be
 able to distinguish multiple elements, as their event.target would
 point to each element as appropriate.

 This isn't a click or whatever event, it's a load/unload event.  The
 a or form isn't doing either.

Sorry, I had in mind being able to re-apply event listeners to the DOM
once the new content was loaded. Of course you can do that in several
localised places rather than overall on the whole document (it will be
more efficient anyway). Still, it would be nice to be able to identify
that all my bits of content are now loaded and being able to have an
event handler that gets called once, rather than having to account for
all the IDs loading independently: I might want to do something that
involves several parts of the new content (e.g. highlight it to make
the change obvious to the user).


Nelson Menezes
http://fittopage.org

Re: [whatwg] object behavior

On Sun, 18 Oct 2009, Ben Laurie wrote:
 On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote:
  On Fri, 16 Oct 2009, Ben Laurie wrote:
   On Thu, 6 Aug 2009, Andrew Oakley wrote:
  
   - Should the type attribute take precedence over the Content-Type
   header?
  
   No, I believe what the spec says here is the preferred behaviour.
   Unless this is incompatible with legacy content, we should try to move
   towards this behaviour.
 
  I realise this is only one of dozens of ways that HTML is unfriendly to
  security, but, well, this seems like a bad idea - if the page thinks it
  is embedding, say, some flash, it seems like a pretty bad idea to allow
  the (possibly untrusted) site providing the flash to run whatever it
  wants in its place.
 
  If the site is untrusted, yet you are letting it run flash, then you've
  lost already. Flash can inject arbitrary JS into your page.
 
 Perhaps I am failing to understand, but if I embed anything from an
 untrusted site, then it can choose what type it is - so how would I
 prevent it running Flash?

You can't exclude one type and allow others, but if you want a very 
specific type used for a plugin, you can use embed. If you just want to 
allow the untrusted site to do anything, but in their own security context 
so it can't harm your site, use iframe.


  If you are worried about security, I recommend using iframe. The new 
  sandbox= feature will help even more, once implemented.
 
 I am worried about security, and I recommend using Caja - but Caja still 
 has to output valid HTML/CSS/JS...

I don't understand the problem.


  On Fri, 16 Oct 2009, Boris Zbarsky wrote:
 
  This cuts both ways.  If a site allows me to upload images and I 
  upload an HTML file with some script in it and tell it it's a GIF 
  (e.g. via the name) an then put an object type=text/html 
  data=http://this.other.site/my.gif; on my site...  then I just 
  injected script into a different domain if we let @type override the 
  server-provided header.
 
  This is, imo, a much bigger problem than that of people embedding 
  content from an untrusted site and getting content X instead of 
  content Y, especially because content X can't actually access the 
  page that contains it, right?
 
  Indeed.
 
 You just said it could, above.

The example Boris mentioned was HTML. Embedded HTML is always 
origin-blocked. The example I mentioned earlier was Flash. Flash runs in 
the context of the embedder page.

HTH,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] object behavior

On Sun, 18 Oct 2009, Ola P. Kleiven wrote:
 On Sun, 18 Oct 2009 14:21:56 +0200, Ben Laurie b...@google.com wrote:
  On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote:
   On Fri, 16 Oct 2009, Ben Laurie wrote:
 On Thu, 6 Aug 2009, Andrew Oakley wrote:

 - Should the type attribute take precedence over the Content-Type
 header?

 No, I believe what the spec says here is the preferred behaviour.
 Unless this is incompatible with legacy content, we should try to move
 towards this behaviour.

I realise this is only one of dozens of ways that HTML is unfriendly to
security, but, well, this seems like a bad idea - if the page thinks it
is embedding, say, some flash, it seems like a pretty bad idea to allow
the (possibly untrusted) site providing the flash to run whatever it
wants in its place.
   
   If the site is untrusted, yet you are letting it run flash, then you've
   lost already. Flash can inject arbitrary JS into your page.
  
  Perhaps I am failing to understand, but if I embed anything from an
  untrusted site, then it can choose what type it is - so how would I
  prevent it running Flash?
 
 Running Flash and allowing the same Flash to script your page are two
 different things. Flash needs allowscriptaccess=always to script if it is
 loaded from a different domain. This may not be true for all plug-ins though.

Ah, good to know.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] No interface flicker across page loads, without JavaScript

On Sun, Oct 18, 2009 at 1:00 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
 a) Avoiding flickering and jumping on page load.
 b) Saving bandwidth.
 c) Being able to preserve state of some parts of the page (e.g.,
 navigation collapse state) when others change (e.g., new content
 loaded).

I intend to solve a combination of (a) and (c) (b might be an
ancillary benefit, however).

Basically, there are two classes of websites who I think will benefit from this.

1. Fairly ordinary sites which have heavy widgetry in their skeleton.
These might be js-based (good semantic scripting often involves
sending something over the wire that's simple and accessible, then
substantially transforming it with js on the client to something more
useful/dynamic), flash-based, or something else entirely.  The idea is
that there are things which are expensive to initialize (in cpu, time,
whatever) that are present on every page.

2. Relatively simple single-page apps.  Something on the scale of
gmail probably won't be able to use this, and that's fine; they're
already making a significant js investment and can afford a bit more
to handle their single-pageness themselves, plus html5 will add
several features to make this easier.  However, a simpler mail client
may benefit significantly from this, as it eliminates a big chunk of
necessary js.  Other apps that have complex scripts that should
maintain their state may benefit too.  The idea here is similar in
that there may be a significant blob of js state that is expensive to
initialize or reload.

Really simple sites with static sections that are *actually* static
won't really see much benefit (the decrease in flickering may be
useful, but it's such a minor benefit that it's not worth engineering
towards).  As well, very complex js-driven applications will have more
complex requirements than can be met by this mechanism, and so won't
benefit from it.  But the middle ground I outlined above has
significant ability to grow, and I think is currently being held back
by the architecture of the web (where every page is a completely
independent resource) and the difficulty/expense of routing around it
with js.

~TJ

Re: [whatwg] a onlyreplace

On Sun, Oct 18, 2009 at 2:31 PM, Nelson Menezes
flying.mushr...@gmail.com wrote:
 Sorry, I had in mind being able to re-apply event listeners to the DOM
 once the new content was loaded. Of course you can do that in several
 localised places rather than overall on the whole document (it will be
 more efficient anyway).

Well, the best way to do this is probably to use event delegation in
the first place, so you don't have to reinitialize listeners every
time.  jQuery makes this extremely easy with the $(target).live(event,
callback) functionality, but it's pretty simple to do by hand as well.

 Still, it would be nice to be able to identify
 that all my bits of content are now loaded and being able to have an
 event handler that gets called once, rather than having to account for
 all the IDs loading independently: I might want to do something that
 involves several parts of the new content (e.g. highlight it to make
 the change obvious to the user).

Worst case, you just have a listener on body which notes the id of
the target as each swapIn event bubbles up to it, and calls some
function when it's received all of them.  This would be really easy to
automate.

~TJ

Re: [whatwg] a onlyreplace

On Sun, Oct 18, 2009 at 1:15 PM, Aryeh Gregor simetrical+...@gmail.com wrote:
 On Sun, Oct 18, 2009 at 1:37 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
 I think the opposite.  If I upgraded my site to this, I'd want nearly
 all the links to onlyreplace.  There's only a handful of same-origin
 links that I'd instead want to trigger a full load.

 It's very common for several web apps to be installed under a single
 domain, with links from one to the others: the wiki, forum, and CMS
 all linking to each other, say.  These links are often added to
 templates by admins as static HTML that the app doesn't even look at.
 Having them break horribly when the next version of the software uses
 onlyreplace isn't helpful.  Basically, if you're outputting *any* HTML
 without parsing and sanitizing it, opt-out isn't acceptable, since you
 *can't* opt out of links in that HTML.  And every web app I'm familiar
 with (admittedly that's about two) does output some HTML without
 parsing and sanitizing it.

 Keep in mind that if you can't opt out when you need to, the link will
 fail.  If you can't opt in when you need to, the link will work, just
 trigger a full reload.  Opt-in is a much better idea for that reason
 alone, given that many apps won't be able to sanitize some of the
 links they output.

This seems compelling.  I agree, then.  @onlyreplace on base defines
the id-list, and then @onlyreplace on links/forms says I should carry
the onlyreplace semantics.  In the former case it's a space-separated
list of IDREFs, in the latter it's a binary attribute.

 You'd just hook the links with javascript and use that to change the
 navigation-pane highlight.  (Or, in some cases, harness CSS, such as
 by using the proposed pseudoclass that matches links to the current
 document.)

 Well, okay.  That completely defeats the ease of use of this proposal, though.

Hmm?  No it doesn't.  The @onlyreplace still makes the page *way*
easier to handle.  Needing a little bit more js to hook extra behavior
around doesn't seem unreasonable.  (It's better than refreshing the
navlist just to highlight a new section.)

~TJ

Re: [whatwg] hgroup functionality absorbed into header?

On Sun, 18 Oct 2009, Kornel Lesinski wrote:
On Sun, 18 Oct 2009 08:54:59 +0100, Ian Hickson i...@hixie.ch wrote:

Your version with split h2 seems to use it only for visual effect.

Not just visual, but presentational, yes, pretty much. It also makes
it clear how to generate the outline.

I don't understand how presentational h2s make outline clear. I
thought they're an exception that didn't work simple outline algorithm:

http://validator.w3.org/check?uri=http%3A%2F%2Fwww.w3.org%2FTR%2Fhtml5%2Foutline=1#outlineresult

and hgroup exists to resolve ambiguity caused by presentational use of
headers.

I mean that it defines exactly what value to use in the outline.

This:

h1The Reality Dysfunction; Space is not the only void/h1

...would result in an outline that had the following title:

The Reality Dysfunction; Space is not the only void

However, this:

hgroup
h1The Reality Dysfunction/h1
h2Space is not the only void/h2
/hgroup

...results in an outline with just:

The Reality Dysfunction

...as desired. (A user agent could also include the subtitle, but it isn't
required.)

I still think that subtitle (subheader, tagline) would be just as
effective, less confusing and less likely to break outline when used
improperly...

How is h2 confusing?

h2 alone isn't. hgroup is the source of confusion.

* Difference between hgroup and header is not obvious. It wasn't to me
when I first saw them, and this isn't first thread about them.

Sure, but people get it pretty quickly. Most of the threads are along the
lines of I don't like it, not It does X where X is wrong.

* Makes meaning of hx overloaded (sometimes it's a header that affects
outline and level or other headers, sometimes it's a subheader that
doesn't do anything that header would).

Have you seen this post?
http://www.onderhond.com/blog/work/the-hgroup-tag I think it sums up
problems quite well.

If those are the problems, then I think we're doing pretty well. There
were a couple of misunderstandings quickly addressed by the comments. As
far as I can tell, the other concerns were all theoretical, such as not
approving of the element taking its meaning from its parents. However,
this is a pattern used all over HTML5, and I don't see why it's a problem.

I think something like subtitle is just as likely to be misused as
hgroup, to be honest.

Sure, but it's much more fail-safe. If you use header instead of
hgroup or fail to use hgroup, you may significantly change structure
of the document.

That's clearly not the end of the world, since people are doing it all the
time today!

You can't make much damage with subheader. Sections will remain
correct and at worst you'll add wrong subtitles to headers.

There's plenty of damage you could make. What if someone decides that
header should be subheader because it's in a section, and they end up
putting entire sections in there, for instance? Authors have an unlimited
capacity for misusing HTML.

Also, it has a much poorer legacy (backwards compatibility) story.

Both solutions have problems. I don't think ones are much worse than the
others.

I think subheader has far bigger problems than hgroup (primarily its
lack of default styles in legacy UAs).

hgroup breaks the outline

I still think this is incorrect. It fixes the outline in new UAs, and has
no effect on legacy UAs.

subheader is ignored. Without CSS h2s will be too large and have too
big margins.

The CSS is already there, though, since people are already using h2 for
this.

With CSS subheader will work fine and doesn't limit styling
possibilities. hgroup's content model doesn't allow any non-header
elements, so one can't add any extra hooks for styling:

hgroup
h1/
div!-- add fancy border around subheaders? --
h2/
h2/
/div
/hgroup

That's a good point. However, in general, I would encourage people to not
insert HTML divs purely for styling; instead, in the future, XBL and CSS
will hopefully provide the tools to address this. (We can always allow
div later if this becomes a real problem.)

Another thing - can you write XPath query that extracts all headers from
the document? Without hgroup it's simple. With hgroup I'm not sure
if I could manage to write correct query.

This problem exists in general in HTML -- can you write an XPath that
selects the elements on a per-section basis, say? Or that selects all the
third-level headers, including the right h1s in sections?

For that kind of thing we'll need pesudo-elements (in Selectors) or custom
functions (in XPath).

--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] object behavior

2009-10-18 Thread Ben Laurie

On Sun, Oct 18, 2009 at 3:47 PM, Ian Hickson i...@hixie.ch wrote:
 On Sun, 18 Oct 2009, Ben Laurie wrote:
 On Sun, Oct 18, 2009 at 5:37 AM, Ian Hickson i...@hixie.ch wrote:
  On Fri, 16 Oct 2009, Ben Laurie wrote:
   On Thu, 6 Aug 2009, Andrew Oakley wrote:
  
   - Should the type attribute take precedence over the Content-Type
   header?
  
   No, I believe what the spec says here is the preferred behaviour.
   Unless this is incompatible with legacy content, we should try to move
   towards this behaviour.
 
  I realise this is only one of dozens of ways that HTML is unfriendly to
  security, but, well, this seems like a bad idea - if the page thinks it
  is embedding, say, some flash, it seems like a pretty bad idea to allow
  the (possibly untrusted) site providing the flash to run whatever it
  wants in its place.
 
  If the site is untrusted, yet you are letting it run flash, then you've
  lost already. Flash can inject arbitrary JS into your page.

 Perhaps I am failing to understand, but if I embed anything from an
 untrusted site, then it can choose what type it is - so how would I
 prevent it running Flash?

 You can't exclude one type and allow others,

Sure, and that's fine.

 but if you want a very
 specific type used for a plugin, you can use embed.

So what's the difference between embed and object?

 If you just want to
 allow the untrusted site to do anything, but in their own security context
 so it can't harm your site, use iframe.

iframe is insufficient to prevent untrusted content from doing harm.
It also makes it painful to communicate with the untrusted content.



  If you are worried about security, I recommend using iframe. The new
  sandbox= feature will help even more, once implemented.

 I am worried about security, and I recommend using Caja - but Caja still
 has to output valid HTML/CSS/JS...

 I don't understand the problem.


  On Fri, 16 Oct 2009, Boris Zbarsky wrote:
 
  This cuts both ways.  If a site allows me to upload images and I
  upload an HTML file with some script in it and tell it it's a GIF
  (e.g. via the name) an then put an object type=text/html
  data=http://this.other.site/my.gif; on my site...  then I just
  injected script into a different domain if we let @type override the
  server-provided header.
 
  This is, imo, a much bigger problem than that of people embedding
  content from an untrusted site and getting content X instead of
  content Y, especially because content X can't actually access the
  page that contains it, right?
 
  Indeed.

 You just said it could, above.

 The example Boris mentioned was HTML. Embedded HTML is always
 origin-blocked. The example I mentioned earlier was Flash. Flash runs in
 the context of the embedder page.

 HTH,
 --
 Ian Hickson               U+1047E                )\._.,--,'``.    fL
 http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
 Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] a onlyreplace

Tab Atkins Jr. wrote:
 On Sun, Oct 18, 2009 at 11:50 AM, Schuyler Duveen
 wha...@graffitiweb.org wrote:
 The problem is that people will make links that refresh different parts
 of a document, to the point that the current document is no longer
 addressable.  Use cases for this happen often enough (not necessarily
 good design, but people will do this)

 In the past, a good way to give (back) addressability to users is with
 hash tags.  But here, the location changes, and the hash goes away.
 Standard anchor tags (with no javascript) have generally been
 addressable to users by default.  When this hasn't been true, like with
 framesets, lots of confusion and frustration ensues.

 If this is, in the longterm, going to work non-dynamically, then things
 should be addressable by default.  It's one of the killer features of
 the web :-)
 
 You're right, and this makes me think more strongly that restricting
 the ability to specify the replaceable bits to just base is the
 right way to do this.
I'm starting to think the addressability is the main constraint.  What
if the original @onlyreplace anchor tag:

   a onlyreplace=id1 id2 href=page2.html /

would be equivalent to something like this:

   a href=#view(page2.html id1 id2) /

which would process onload or onhashchange as we've been describing
@onlyreplace and would appear in the browser's location bar.  A more
complicated one (after two jumps) might look something like:

http://example.com/page1.html#view(page2.html id1 id2);view(page3 id3)

/sky

Re: [whatwg] a onlyreplace

On Sun, Oct 18, 2009 at 9:42 PM, Schuyler Duveen wha...@graffitiweb.org wrote:
 Tab Atkins Jr. wrote:
 On Sun, Oct 18, 2009 at 11:50 AM, Schuyler Duveen
 wha...@graffitiweb.org wrote:
 The problem is that people will make links that refresh different parts
 of a document, to the point that the current document is no longer
 addressable.  Use cases for this happen often enough (not necessarily
 good design, but people will do this)

 In the past, a good way to give (back) addressability to users is with
 hash tags.  But here, the location changes, and the hash goes away.
 Standard anchor tags (with no javascript) have generally been
 addressable to users by default.  When this hasn't been true, like with
 framesets, lots of confusion and frustration ensues.

 If this is, in the longterm, going to work non-dynamically, then things
 should be addressable by default.  It's one of the killer features of
 the web :-)

 You're right, and this makes me think more strongly that restricting
 the ability to specify the replaceable bits to just base is the
 right way to do this.
 I'm starting to think the addressability is the main constraint.  What
 if the original @onlyreplace anchor tag:

   a onlyreplace=id1 id2 href=page2.html /

 would be equivalent to something like this:

   a href=#view(page2.html id1 id2) /

 which would process onload or onhashchange as we've been describing
 @onlyreplace and would appear in the browser's location bar.  A more
 complicated one (after two jumps) might look something like:

 http://example.com/page1.html#view(page2.html id1 id2);view(page3 id3)

Hmm, that's interesting.  So, rather than simply changing the url and
hoping that the author is maintaining the correct semantics (so that
visiting the url fresh gives you same/similar results), you just
explicitly express that the page is a combination of multiple pages.

I suppose that if, in your example, you then clicked a a
href=page4.html onlyreplace=id3, the url would change to
http://example.com/page1.html#view(page2.html id1 id2);view(page4.html
id3); that is, it would record the location each segment was drawn
from, but not the full history, as that is irrelevant for regenerating
the page.

Then bookmarking that url and visiting it again would presumably make
3 separate requests, once for page1 for most of the page, and then for
page2 and page4 for the particular ids.  Right?

~TJ

Re: [whatwg] a onlyreplace

Tab Atkins Jr. wrote:
 On Sun, Oct 18, 2009 at 9:42 PM, Schuyler Duveen wha...@graffitiweb.org 
 wrote:
 Tab Atkins Jr. wrote:
 On Sun, Oct 18, 2009 at 11:50 AM, Schuyler Duveen
 wha...@graffitiweb.org wrote:
 The problem is that people will make links that refresh different parts
 of a document, to the point that the current document is no longer
 addressable.  Use cases for this happen often enough (not necessarily
 good design, but people will do this)

 In the past, a good way to give (back) addressability to users is with
 hash tags.  But here, the location changes, and the hash goes away.
 Standard anchor tags (with no javascript) have generally been
 addressable to users by default.  When this hasn't been true, like with
 framesets, lots of confusion and frustration ensues.

 If this is, in the longterm, going to work non-dynamically, then things
 should be addressable by default.  It's one of the killer features of
 the web :-)
 You're right, and this makes me think more strongly that restricting
 the ability to specify the replaceable bits to just base is the
 right way to do this.
 I'm starting to think the addressability is the main constraint.  What
 if the original @onlyreplace anchor tag:

   a onlyreplace=id1 id2 href=page2.html /

 would be equivalent to something like this:

   a href=#view(page2.html id1 id2) /

 which would process onload or onhashchange as we've been describing
 @onlyreplace and would appear in the browser's location bar.  A more
 complicated one (after two jumps) might look something like:

 http://example.com/page1.html#view(page2.html id1 id2);view(page3 id3)
 
 Hmm, that's interesting.  So, rather than simply changing the url and
 hoping that the author is maintaining the correct semantics (so that
 visiting the url fresh gives you same/similar results), you just
 explicitly express that the page is a combination of multiple pages.
 
 I suppose that if, in your example, you then clicked a a
 href=page4.html onlyreplace=id3, the url would change to
 http://example.com/page1.html#view(page2.html id1 id2);view(page4.html
 id3); that is, it would record the location each segment was drawn
 from, but not the full history, as that is irrelevant for regenerating
 the page.
 
 Then bookmarking that url and visiting it again would presumably make
 3 separate requests, once for page1 for most of the page, and then for
 page2 and page4 for the particular ids.  Right?
Exactly.

These are the use cases I think we're targeting with such addressability:
(when considering some server-side request filter, as well)
1. Avoid flicker and state-reinitialization between similar pages.
2. preserve scroll context across loading similar pages.
3. robots crawling ajax-states reliably (and efficiently)
4. standardize addressability of (most) ajax states
5. Provide AJAX features to static pages that
   are low-hanging fruit.
   (considered as those mentioned above)
6. AJAX pages could also use more structure in the hash-tag
   e.g. to preserve their own state in the hash even while a user
   visits a specific part of the page
7. simplify very standard behavior in AJAX sites, especially in
   contexts that affect accessibility (like dynamic form submission)

/sky

Re: [whatwg] object behavior

2009-10-18 Thread Simon Pieters


On Sun, 18 Oct 2009 23:48:51 +0200, Ian Hickson i...@hixie.ch wrote:


On Sun, 18 Oct 2009, Ben Laurie wrote:


 but if you want a very specific type used for a plugin, you can use
 embed.

So what's the difference between embed and object?


embed only allows plugins; object also allows other things, like HTML
and images.


embed also allows images (including SVG with scripts), at least in  
browsers.


--
Simon Pieters
Opera Software

Re: [whatwg] Superset encodings [Re: ISO-8859-* and the C1 control range]