Re: [whatwg] style sheet blocking scripts
I understand now. Thank you for your answers. From: hy...@apple.com Date: Thu, 10 Dec 2009 12:15:50 -0600 To: jam...@google.com CC: wha...@whatwg.org; bzbar...@mit.edu; i...@hixie.ch; t_gars...@hotmail.com Subject: Re: [whatwg] style sheet blocking scripts On Dec 9, 2009, at 4:10 PM, James Robinson wrote:2009/12/9 tali garsiel t_gars...@hotmail.com Well, not completely.Regarding the first question- Webkit guys told me (on their IRC channel) that the don't block the parser and only block scripts that request visual information, so I'm still confused. Here's my understanding of the implementation inside WebKit currently:During parsing, WebKit does not block the parser on stylesheet loads, but does block external scripts from running until previously-encountered stylesheets have loaded. WebKit does not suspend script execution on requests for visual information if stylesheets have not loaded (for example for inline scripts or in the case of stylesheets added dynamically after parsing has completed). WebKit does suspend parsing of the document on script loads, but has a speculative preloader to attempt to start fetches for resources past the script tag. - James This is accurate, although I'd add that we consider it a bug that we don't yet block the parser for inline scripts in addition to external scripts. dave _ Windows Live: Make it easier for your friends to see what you’re up to on Facebook. 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_2:092009
[whatwg] style sheet blocking scripts
Hi, This is a quote from Section 4.2 of the spec: A style sheet in the context of the Document of an HTML parser or XML parser is said to be a style sheet blocking scripts if the element was created by that Document's parser, and the element is either a style element or a link element that was an external resource link that contributes to the styling processing model when the element was created by the parser, and the element's style sheet was enabled when the element was created by the parser, and the element's style sheet ready flag is not yet set, and, the last time the event loop reached step 1, the element was in that Document And the section about parsing - the script tag says that before executing a script the parser must: 3. Spin the event loop until there is no style sheet blocking scripts and the script's ready to be parser-executed flag is set. I have two questions: 1. As far as I know, Firefox and Webkit have a stall on demand behavior, where a stylesheet blocks a script only if the script asks from style information. According to the spec the style sheet always blocks a script, am I right? 2. Can you clarify the condition - the element's style sheet was enabled when the element was created by the parser, and the element's style sheet ready flag is not yet set, and, the last time the event loop reached step 1, the element was in that Document Does it mean the style sheet blocks scripts only if it's currently being parsed? Tali _ Windows Live: Make it easier for your friends to see what you’re up to on Facebook. 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_2:092009
Re: [whatwg] a onlyreplace
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] a onlyreplace
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
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] framesets
pine.lnx.4.62.0910130924420.25...@hixie.dreamhostps.com 4ad4a1eb.8080...@artfulsoftware.com pine.lnx.4.62.0910132224110.6...@hixie.dreamhostps.com 4ad5438d.3090...@artfulsoftware.com 98038259-77f7-42fd-8a4a-097bb3e9e...@dartmouth.edu 4ad57761.4060...@artfulsoftware.com 5ccfb3340910140023s65dbb96bq988b96b55707a...@mail.gmail.com 4ad5f4a5.2040...@artfulsoftware.com a440ea080910150049t42482beav46a76a597ba29...@mail.gmail.com Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Nelson wrote: There is a specific use-case (that has nothing to do with databases or bookmarking) that framesets solve better out-of-the box right now in most browsers: that of a panel-based layout that allows resizing and maintains UI state without flickering whilst loading content in different panel 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. Maybe there is room for a better, standard-based approach to solving this issue, but framesets ain't it. I totally agree. I think the described case is the main flow in web applications. I think most web applications have exactly this panel based layout, where navigation loads only a some of the panels. I think they all use AJAX. Iframes are very unpopular, and as you say AJAX is the best current solution. I think there should be a standard based solution because: 1.Even when using libraries like prototype, AJAX does take some coding. Why should I use so much code for such a simple, main flow use case? 2.By looking at browsers code I see there is a lot of clever stuff going on when loading/unloading a document. In the AJAX based solution this happens only once in the application life cycle. It seems to me that dedicating a special syntax to navigation would help browsers to test the application main flow. Tali From: flying.mushr...@gmail.com Date: Thu, 15 Oct 2009 09:49:58 +0200 To: p...@artfulsoftware.com CC: wha...@whatwg.org Subject: Re: [whatwg] framesets Wow, what a tour de force; 78 messages and no progress. Peter, I believe the only reason the discussion has carried so far is because you are, actually, on to something. You just don't seem very aware that people are actually trying to pin down and solve the something and keep banging on about framesets being the cure-all, whilst ignoring other points. Here's (yet another) summary: 1) Framesets have been deprecated for quite a long time. The reasons for the deprecation have been repeated ad nauseam, and very solid. 2) There is a specific use-case (that has nothing to do with databases or bookmarking) that framesets solve better out-of-the box right now in most browsers: that of a panel-based layout that allows resizing and maintains UI state without flickering whilst loading content in different panels (this is, I believe, the something you're getting at). 3) There are HTML5-conformant solutions available right now that allow you to replicate the above scenario with a little more work. The iframes solution with a bit of JS [1] [2] for handling the resizing is probably the easiest to implement, although an analogous solution with AJAX is probably the best available (which allows for deep-linking when this is desirable and doesn't automatically break bookmarking). You can also (if you wish) break bookmarking/the back button with these solutions, especially the AJAX one. There is also the CSS position: fixed solution that will be adequate for a large number of scenarios, or can complement the other two. 4) As repeated many times, you don't have to use HTML5. Keep using HTML 4 Frameset [3] if you insist on using the frameset solution and care about validation. The documents within each frame can be HTML5. Or use HTML5 with framesets -- it won't validate but is guaranteed (by the spec) to work. Do expect to run into the usability problems inherent to frames, though. 5) There is a known need for CSS to handle the above panel resizing use-case. That is a first-class CSS problem; don't expect the HTML spec to address that, especially not with a mechanism (framesets) that has many drawbacks and is deprecated for good reasons. For immediate solutions, see 3) and 4) above. 6) For clarity sake, I'll repeat the point made several times:the bookmarking/navigation/security issue is *not* solved by framesets, and the slight hack to make this work (javascript's replace) as you suggest is neither exclusive to framesets nor (in the case of security) acceptable. 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. Maybe there is room for a better, standard-based approach to
Re: [whatwg] framesets
relegate a perfectly sound use case to a cul-de-sac? It would be a bad idea to relegate a perfectly sound use case to a cul-de-sac. But that's not what we're doing. The use case is still handled fine, in a number of ways (e.g. iframes, Ajax-based navigation). The feature we're relegating to a cul-de-sac is not perfectly sound. On Fri, 9 Oct 2009, Peter Brawley wrote: It's not your brief to decide what's beneficial for a client. Actually, it sort of is. It conflicts with expected behavior. It does not conflict with what these users expect. Framesets actually do conflict significantly with what most users expect; that's one of their problems. Framesets are part of the current HTML standard and should remain. Actually framesets were deprecated in 1998. They've been on the chopping block for over ten years now. Their use is _so_ discouraged in HTML4 that they are not even included in the Transitional DTD, they are relagated to their own third-tier DTD. On Fri, 9 Oct 2009, Peter Brawley wrote: I quoted Andrew Fedoniouk (http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-March/010186.html), There are use cases when frames are good. As an example: online (and offline) help systems ... In such cases they provide level of usability higher than any other method of presenting content of such type. I've not seen a counterexample. Have you? I believe Andrew's statement to be incorrect. I would argue that the usability of help sites based on framesets is horrible. For example, search engines can't index into them (search is a critical part of help systems), pages in them can't easily be bookmarked and URLs to them can't be shared with other people (another critical part of help systems), and using the open in new tab feature on index pages of help systems that use framesets ends up breaking the frameset, making browsing multiple aspects in parallel difficult. On Sat, 10 Oct 2009, tali garsiel wrote: 1. Tabs and tree menu navigation is very common in web applications. Do you agree with that assumption? Tabs are a media-specific presentation issue, and don't belong in HTML. Tree menu navigation is a use case we need to fix anyway, and will probably do so in the next version of HTML. (We were going to do it in HTML5, but had to punt because we couldn't get the detailed nailed down. It's a hard thing to get right.) However, that's independant of frames. The problem exists regardless of what the look is, one frame or many. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' _ Windows Live: Make it easier for your friends to see what youre up to on Facebook. 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_2:092009
Re: [whatwg] framesets
pine.lnx.4.62.0910121145480.25...@hixie.dreamhostps.com Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 I guess it's not a HTML5 question but more a best practice question but ... In case an application has navigation menus that cannot be reloaded each time.Only the content part should be reloaded. What is a better 1. Using an iframe for the content and fixing bookmarking/back button 2. Using Ajax to update the content - a single document application The issue with the later option is not user experience but browser performance. Is never reloading the document, only updating the DOM harmful? (like caches wont be cleaned , garbage collection will not be done properly) . Maybe it's browser specific but it also has to do with what browsers are supposed to support and test. Date: Mon, 12 Oct 2009 11:46:37 + From: i...@hixie.ch To: t_gars...@hotmail.com CC: wha...@whatwg.org Subject: RE: [whatwg] framesets On Mon, 12 Oct 2009, tali garsiel wrote: Does pushState apply to bookmarking? Insofar as bookmarking uses the document's current address, yes. (Bookmarking, being a UI feature, isn't defined in HTML5.) -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' _ Windows Live: Make it easier for your friends to see what youre up to on Facebook. 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_2:092009
Re: [whatwg] framesets
7c2a12e20910091119j2e527fc7x3e50e668342a9...@mail.gmail.com 4acf873d.6000...@artfulsoftware.com 4acf8b51.80...@mit.edu 4acf9e08.1020...@artfulsoftware.com a9699fd20910091521p5d4bdd19l118e9699cbf74...@mail.gmail.com 4acfcb99.1040...@artfulsoftware.com 6ea53250910091718md017d92xe32e244fca334...@mail.gmail.com 4ad009b2.9040...@artfulsoftware.com 6ea53250910101207l3c190722he405b983fc7ba...@mail.gmail.com Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 I agree with Peter that this type of document navigation is an extremely common use case. I think the use case includes navigation that loads only parts of the page, leaving the other parts static. Almost all web applications I know have tabs on top and a tree on the left. The idea is not repainting the tabs/tree etc on every click to keep a good user experience. On the old days frames were used, then a tables + iframes. Then iframes where considered bad design and I think most applications use divs + css + Ajax. In my experience this is not good either and causes serious performance issues. I think its called single page design where the browser is never told to unload a document and reload another but just to keep updating the DOM using Ajax with huge chunks of HTML. I think its important that the W3C specification should provide a good solution for this common case. Regards, Tali From: herenva...@gmail.com Date: Sat, 10 Oct 2009 21:07:42 +0200 To: p...@artfulsoftware.com CC: wha...@whatwg.org; t.bro...@gmail.com; bzbar...@mit.edu Subject: Re: [whatwg] framesets On Sat, Oct 10, 2009 at 6:12 AM, Peter Brawley wrote: [lots...] Now, your last mail does describe the use-cases and their presumed requirements. Your wording is maybe a bit messy, but you have at least provided something worth discussing. Just to make sure I (and others) are understanding your proposal as intended, I'll try to paraphrase it in a more structured way (please, if I got something wrong, just let me know): Use case: displaying tree-based content (editable or not). (Note: I'm omitting the database aspect because it only matters on the server side: once on the client, the page doesn't care whether the data comes from/goes to a database, a collection of files, or anywhere else). Requirements: 1) The display will use multiple subwindows, such as header, tree-view, and content (the names are arbitrary, hope they are descriptive and concise). 2) The subwindows (or some of them) need to be independently scrollable. 3) The subwindows must be resizable. 4) The tree structure being displayed may be protected through some permission mechanism, so each user only gets to see or interact with the nodes such user has permissions for. 5) The back button and bookmark features shouldn't work. So far, so good. Just if you had gone a bit further... That's a use-case with a series of requirements. This is a good beginning, but let's go to the next steps. Requirement justification: you haven't provided any (it's the requirements, not the use-case itself, what needs to be justified; a use-case is inherently justified by the real-world needs it addresses). For requirements 1 to 3, I can assume as an implicit justification something like this is the behavior every user would expect or anything like that, so let's move forward. For requirement 4, things are a bit weird: should authentication be handled on the server or on the client side? It seems that it has to be handled on the server side, so the nodes a user is not allowed to see should never be sent to the client (otherwise, the user could look at the source, hack through grease-monkey scripts, or override the permission system in many ways). If it's handled by the server, then it isn't relevant to HTML: HTML is a client-side language. If there is some need to handle (part of) the authentication issue from the client, you should provide more details and justify such need; otherwise the requirement can just be omitted as it wouldn't be relevant. Requirement 5 does need some justification. In my opinion, there is no need on your use case for these features (back button and bookmarks) to work, but is there any real need for them to break? If there is, please justify it; if there isn't, then that's not a requirement (it would just be the absence of a requirement for these features to work). Not needing them to work is *not* the same as needing them to break. Now, leaving aside the issues with the last two requirements, we can move forward. The next step would be to see which requirements are met by currently existing solutions, and which aren't. I will be ignoring for now Requirement 4 because it's unclear what the actual requirement would be. First, let's look at what the currently existing solutions are: I may be
Re: [whatwg] framesets
6ea53250910101207l3c190722he405b983fc7ba...@mail.gmail.com bay117-w2cc232231c30158f2fed583...@phx.gbl 6ea53250910101551x5239027end5fc1b52cea81...@mail.gmail.com Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 What I'm saying is based on my experience. I'v been involved in developement of large and complex web application for the last 9 years. I know this discussion is getting too long but I believe it's because it touches a real problem. Lets try to see where we disagree. 1. Tabs and tree menu navigation is very common in web applications. Do you agree with that assumption? Possible solutions for creating such navigation are: 1. Using one page + server side includes to repaint the navigation every time. Not good.From my experience it burdens the server (it's not just images - its reading the XML that describes the tabs , calculating tree permissions , getting the whole tree data from the database etc) and causes a noticeable flicker. 2. Using frames - not good from the reasons you pointed out 3. Using iframes - not good from the same reasons 4. Using ajax - not good.From my experience browsers know how to load documents and don't react well in a situation where there is one document and every screen is built by updating the DOM of this document.I think the tests browser do do not include such cases and its not how they are meant to act. So - for an extremely common use case there is no solution at all. Again , please specify where you disagree. Solution - I don't have a detailed solution but I think that the applications outer structure should be described by special tags which will behave well with bookmarking and the back button. In outer structure I mean the part of the layout that consistently appears in each screen. Tali From: herenva...@gmail.com Date: Sun, 11 Oct 2009 00:51:53 +0200 To: t_gars...@hotmail.com CC: p...@artfulsoftware.com; t.bro...@gmail.com; bzbar...@mit.edu; wha...@whatwg.org Subject: Re: [whatwg] framesets On Sun, Oct 11, 2009 at 12:15 AM, tali garsiel wrote: I agree with Peter that this type of document navigation is an extremely common use case. I think the use case includes navigation that loads only parts of the page, leaving the other parts static. Almost all web applications I know have tabs on top and a tree on the left. The idea is not repainting the tabs/tree etc on every click to keep a good user experience. On the old days frames were used, then a tables + iframes. Then iframes where considered bad design and I think most applications use divs + css + Ajax. Peter's case is quite legitimate; I just asked for him to properly detail it so it can be properly discussed. Your reference to the old days, however, scares me a bit: on the old days there weren't many web applications, only web pages. If you are trying to argue for sites (made of pages or documents) that use s to keep the menus and headers static, I must stronly oppose that: while neglecting the back button, bookmarking and deep-linking features inherent to the web may be acceptable for some specific applications, this is absolutely a bad idea for classic pages: these elements do not take that much to load (and, if they use images, the browser will have them cached anyway), and all other advantages of using frames in this scenario (such as maintaining a single instance of the menu) are far better handled through server-side solutions such as includes. Being unable to deep-link to (or bookmark) a specific page on a site is a serious drawback; hence any site that considers breaking such capabilities must accurately weight the cost of the drawback against the value of the benefits it expects to achieve from it. If you have specific use-cases for Peter's proposal, you're welcome to bring them forward... oh, wait... what's Peter's proposal? I think its important that the W3C specification should provide a good solution for this common case. You know, solutions don't come out of thin air: they are proposed by contributors to the lists like you, or me, or anyone else here. If you know the cases you want to have addressed, then I strongly encourage you to suggest a solution. The same advise I gave Peter applies: make sure to describe the use-cases you are addressing, detailing the requirements (and justifying them when they aren't 100% obvious), showing where current solutions fail, and showing that your proposal meets all the requirements. Honestly, I don't think that this process is ideal, but it's the way things are normally done here, and I can't think of a better process (otherwise I'd bring it forward). Some discussion on the abstract can be useful, but at the end of the day, only solutions that address use-cases and meet requirements make it into the spec. Finally, let me insist on a small detail that seems
Re: [whatwg] framesets
6ea53250910101207l3c190722he405b983fc7ba...@mail.gmail.com bay117-w2cc232231c30158f2fed583...@phx.gbl 6ea53250910101551x5239027end5fc1b52cea81...@mail.gmail.com Content-Type: text/plain; charset=windows-1255 Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Here is my suggestion - adding a type and navigation-state attributes to frameset in order for bookmarking , deep linking and back button to work. Something like: frameset type=navigation navigation-state=1 //here I put my tabs frameset type=navigation navigation-state=1 //here I put the menu frame type=content //the content /frameset /frameset The browser will keep a match between the navigation-state of the navigation frames and the URL of the content frame. use case: The user clicks a tab - the navigation-state will change using JavaScript from 1 to 2, the content frame is reloaded. The user clicks the bookmark button. The browser puts in the bookmark storage the new content URL + the new state. When the bookmark is invoked the browser loads tabs and menu frames and exposes the navigation state to them.It also loads the content with the new URL. The tabs frame uses the state information to display the correct tab using JavaScript. Something like history.navigationState. The tab and menu frames might be in different navigation states. There can be a combination of tabs in state 1 , tree in state 2 , content URL is x. The browser will remember the combination when bookmarking. Tali From: herenva...@gmail.com Date: Sun, 11 Oct 2009 00:51:53 +0200 To: t_gars...@hotmail.com CC: p...@artfulsoftware.com; t.bro...@gmail.com; bzbar...@mit.edu; wha...@whatwg.org Subject: Re: [whatwg] framesets On Sun, Oct 11, 2009 at 12:15 AM, tali garsiel wrote: I agree with Peter that this type of document navigation is an extremely common use case. I think the use case includes navigation that loads only parts of the page, leaving the other parts static. Almost all web applications I know have tabs on top and a tree on the left. The idea is not repainting the tabs/tree etc on every click to keep a good user experience. On the old days frames were used, then a tables + iframes. Then iframes where considered bad design and I think most applications use divs + css + Ajax. Peter's case is quite legitimate; I just asked for him to properly detail it so it can be properly discussed. Your reference to the old days, however, scares me a bit: on the old days there weren't many web applications, only web pages. If you are trying to argue for sites (made of pages or documents) that use s to keep the menus and headers static, I must stronly oppose that: while neglecting the back button, bookmarking and deep-linking features inherent to the web may be acceptable for some specific applications, this is absolutely a bad idea for classic pages: these elements do not take that much to load (and, if they use images, the browser will have them cached anyway), and all other advantages of using frames in this scenario (such as maintaining a single instance of the menu) are far better handled through server-side solutions such as includes. Being unable to deep-link to (or bookmark) a specific page on a site is a serious drawback; hence any site that considers breaking such capabilities must accurately weight the cost of the drawback against the value of the benefits it expects to achieve from it. If you have specific use-cases for Peter's proposal, you're welcome to bring them forward... oh, wait... what's Peter's proposal? I think its important that the W3C specification should provide a good solution for this common case. You know, solutions don't come out of thin air: they are proposed by contributors to the lists like you, or me, or anyone else here. If you know the cases you want to have addressed, then I strongly encourage you to suggest a solution. The same advise I gave Peter applies: make sure to describe the use-cases you are addressing, detailing the requirements (and justifying them when they aren't 100% obvious), showing where current solutions fail, and showing that your proposal meets all the requirements. Honestly, I don't think that this process is ideal, but it's the way things are normally done here, and I can't think of a better process (otherwise I'd bring it forward). Some discussion on the abstract can be useful, but at the end of the day, only solutions that address use-cases and meet requirements make it into the spec. Finally, let me insist on a small detail that seems to go unnoticed regardless of how many times it has been repeated in the last hours: HTML5 updates/replaces the Transitional and Strict doctypes of HTML4. HTML4 Frameset isn't being updated as of now, and it stays valid, legitimate, and current. Using a HTML4 Frameset master page that shows HTML5 documents on its frames is valid and conformant
[whatwg] The removal of datalist
Hi, Will this element come back? From my experience web applications always contains: 1. A tree control 2. A sortable data grid with a data provider All js libraries like dojo , ext js etc have this elements(and of course all libraries like swing). If such a basic GUI element will not be included in HTML , then web application authors will still need to use a js widget library. This library will still need to do crazy tricks and workaround to build controls which look like the real thing. I think HTML should provide the basic controls + some way for extending them , otherwise we go back to where we started. Tali _ More than messages–check out the rest of the Windows Live™. http://www.microsoft.com/windows/windowslive/
