Re: [whatwg] defer on style, depends
On Mon, 9 Feb 2009, Boris Zbarsky wrote: Ian Hickson wrote: I'm not convinced either of these are really great solutions. I think it'd be better just to have the script itself only block when it hits CSS-dependent APIs (though I recognise that that is a much harder problem in most rendering engines today). I'm not sure how you envision this working. The run-to-completion semantics mean that while the script is working on the API call to return (which means that network events are being processed, etc), the following invariants need to be maintained (list very much not exhaustive): 1) No setTimeout timers fire. 2) No XMLHttpRequest state changes happen. 3) No image load events fire. 4) No stylesheet load events fire (for UAs that implement such an event on their link elements, as Gecko would like to do). 5) No user interaction with the page or other pages that can reach the given page is allowed. #5 makes it unlikely that a UA would want to go this route at all. #4 means that this approach would be incompatible with reasonable style load events... #1, #2, #3 all mean that networking needs to differentiate between the set of stylesheets we're waiting on and everything else. Yeah, fair enough. By the way, the spec doesn't yet require the blocking behavior. I couldn't work out how to do it. Could you elaborate on when exactly in the process the style sheet is waited on? Does it happen for all scripts? For example, if a script inserts a style sheet and then a script, does that script wait for the style sheet to load? On Mon, 9 Feb 2009, Garrett Smith wrote: If I put the script at the bottom of the page, and a linked stylesheet in the head, the script waits for the stylesheet. I want my page to load faster and this feature prevents it. Put the script in the head before the style sheet and use the defer attribute so that it runs the script as if it was at the end of the page. It seems pretty simple to me; if you want the style to be loaded when the script runs, put the style first. If you don't, put the script first and defer it (or mark it async). Why should this not be enough? The implementation might delayed the page from rendering when it sees the stylesheet. That's unrelated to scripts, though, right? If you don't want the script to block page load, then speak to your browser vendor. The spec doesn't require that. The script's defer attribute does not work in a majority of implementations. For such browsers, it makes sense to put the script lower on the page for performance reasons, not before the linked stylesheets. Moving the deferred script from the bottom of the page to the head, just before the stylesheet would mean that those scripts would load first. This would prevent the page content from loading until those scripts had loaded. This would hurt performance in the majority of browsers in use today. Sure, but then the feature you describe doesn't work in today's browsers either, so that seems like a wash. On Mon, 9 Feb 2009, Garrett Smith wrote: There are two/three issues. 1) want to load stylesheets without having scripts block Put the scripts first. 2) want to load stylesheets later, (infoPanel example) Put the styles later. 3) (2), but want to make sure the stylesheet is loaded before the script runs. Put the styles first. Example 1: headtitle/title link independent type=text/css ... script.../script I want the browser to: 1) load my stylesheet and then immediately begin to load script in parallel. Put the script first with a defer or async attribute. Example 2 headtitle/title link defer type=text/css id=lateBoundCSS ... /head body ... script depends=lateBoundCSS.../script /body I want the browser to: 1) defer my linked stylesheet id=lateBoundCSS until content is rendered 2) render content 3) upon encountering the deferred script, check the depends 4) upon finding Result(3) is lateBoundCSS, wait for that resource to finish load before running. I don't really think that makes sense. Why would you depend on just one style sheet and not the others? What if the others change the styles of the content you're dealing with? You could do this, however, using a 'load' event listener on the link (though the spec doesn't yet support that -- I'm trying to reduce the amount of stuff I do using progress events until progress events is further along REC track), or, more simply, by just waiting for the document-wide 'load' event (though that won't wait for just the style sheet, it'll wait for everything). On Mon, 9 Feb 2009, Boris Zbarsky wrote: Not sure what this example is, or why this is insufficienty served by, say, putting the link at the end of the HTML (assuming HTML allowed that, of course). The markup doesn't allow it but you can always do it from script. On Mon, 9 Feb 2009, Garrett Smith wrote: In browsers that do not support defer,
Re: [whatwg] Author control over media preloading/buffering
On Fri, Feb 13, 2009 at 12:55 AM, Robert O'Callahan rob...@ocallahan.org wrote: I don't really see a usecase for multiple priority levels. Do you have one? i've seen a lot of places of late which have multiple videos which are expected to play in some sort of sequence. just saying 'autobuffer' for all of them would kill my device, but a suggestion of which ones to buffer in order would be helpful.
Re: [whatwg] defer on style, depends
Ian Hickson wrote: By the way, the spec doesn't yet require the blocking behavior. I couldn't work out how to do it. Could you elaborate on when exactly in the process the style sheet is waited on? Does it happen for all scripts? For example, if a script inserts a style sheet and then a script, does that script wait for the style sheet to load? The current Gecko behavior is that any stylesheet load started by parsing a style or link tag will increment a counter on the document (well, on a per-document script loader object, to be more precise). Completion of the load will decrement the counter. While the counter is nonzero, script execution is blocked. When it goes back to 0, the first pending script (if any) is run. If this increments the counter again, no more scripts are run until the count goes to 0 again. So it doesn't matter how the script is created/inserted, but the only stylesheets that block scripts are ones that the parser knows about. So only the ones present in the original source or added via document.write. If you createElement a link and insert it into the DOM, it won't block script execution. Also, link elements pointing to alternate style sheets don't block script execution. Let me know if you want more details about any part of this. On Thu, 12 Feb 2009, Boris Zbarsky wrote: I'm proposing flagging scripts that don't depend on stylesheets It seems like it is likely that such a feature would end up used before it works, with the result being that implementors get forced to not support it (a typical race to the bottom seen in browser implementation). Yeah, I did mention that as an explicit worry... -Boris
Re: [whatwg] defer on style, depends
On Fri, 13 Feb 2009, Boris Zbarsky wrote:
The current Gecko behavior is that any stylesheet load started by parsing a
style or link tag will increment a counter on the document (well, on a
per-document script loader object, to be more precise). Completion of the load
will decrement the counter. While the counter is nonzero, script execution
is blocked. When it goes back to 0, the first pending script (if any) is run.
If this increments the counter again, no more scripts are run until the count
goes to 0 again.
So it doesn't matter how the script is created/inserted, but the only
stylesheets that block scripts are ones that the parser knows about. So only
the ones present in the original source or added via document.write. If you
createElement a link and insert it into the DOM, it won't block script
execution. Also, link elements pointing to alternate style sheets don't
block script execution.
So in this:
!DOCTYPE html
...
script
document.write('link rel=stylesheet href=style');
document.write('scripta();\/script');
b();
/script
...is the script paused after the second document.write() call, before a()
and b() execute?
(When replying please leave your text above in the reply, so that I don't
lose context -- thanks!)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Color attributes
On Wed, 11 Feb 2009, Simon Pieters wrote: On Wed, 11 Feb 2009 01:22:59 +0100, Ian Hickson i...@hixie.ch wrote: On Thu, 16 Oct 2008, Simon Pieters wrote: Color attributes in HTML have special processing. [...] It seems that some pages use three-digit notation and expect it to work as in CSS. I've made the algorithm do that and I've drafted up a spec for this: http://simon.html5.org/specs/html-color-attributes The spec now defines this. It seems the spec lacks the CSS2 system colors and 'transparent'. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Styling of area elements (as displayed within referencing image)
On Wed, 11 Feb 2009, L. David Baron wrote: http://www.whatwg.org/specs/web-apps/current-work/#image-maps-0 That text seems ambiguous in the case of values like 'cursor: inherit' on area elements (and the possibility of future values that also take values from the parent element). In particular, the text: # has a value explicitly specified (as opposed to inheriting it # from the element's parent) seems self-contradictory regarding 'cursor: inherit'. I've reworked this to use another approach that should make more sense. Let me know if it still has problems. Since an area element can be hooked up to several img elements, the getComputedValue() API still returns the value from the original element (inheriting from its real parent). I hope that's ok. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spellchecking mark III
On Thu, 12 Feb 2009, Kristof Zelechovski wrote: Regarding http://html5.org/tools/web-apps-tracker?from=2800to=2801, my requests: 1. Change the literals true/false to on/off, leaving the DOM values Boolean. There are three of these attributes so far: autocomplete = on/off contenteditable = true/false draggable = true/false I used true/false for spellcheck since it had slightly more other attributes doing the same thing. Also, it's been implemented twice now, so using other keywords is a problem. 2. Check the spelling of the passage (asits!) :0) Fixed. 3. Say that the default behavior for BODY is on and the default behavior for INPUT[type=text] is off. The default behavior is user-agent-dependent. This is intentional since different users may have different needs. 4. (I understand that it is implicit that this SHOULD indicate does not make tiny clients that do not have the resources non-compliant?) Correct. Stretching it a bit, a user's language always matches the site's, otherwise the user would not be able to submit to the site anything that makes sense, except when the site is a gateway for submissions to an uninvolved third party, in which case said submissions should be tagged with the language of submission anyway (IMHO). On Thu, 12 Feb 2009, Bil Corry wrote: Let me give you an example where this isn't true. I'm in the United States and I do contract work for a company in Germany. At the German company, they have an internal bug tracker for their intranet applications. Usually the bug descriptions are written in German, except mine, which are in English. So they will submit bugs in both German and in English, depending on who is taking care of the issue. How do you envision the UA will determine which language the user is writing in? And what happens when the user submits both German AND English, for two audiences? On Thu, 12 Feb 2009, Kristof Zelechovski wrote: The server has two ways of knowing the user's preferred language: the user's preferences and the browser settings, in that order. Submitting in two languages usually needs two controls, one for English and one for German, with appropriate markup. The server must be prepared to handle this use case. On Thu, 12 Feb 2009, Aryeh Gregor wrote: Both of which are often wrong. Users may be multilingual, and multiple users may use the same computer. On the forum I administer, I post almost exclusively in English. However, sometimes I find occasion to write a post partly or wholly in Hebrew. How is the site supposed to know when I'll decide to do that before I even start typing the post? How can the site ever be sure what language the user will type until he actually starts typing? The server might be able to make an educated guess as to what language will be entered, but so can the browser. And the browser is in a *much* better position to check that guess, because it has access in real time to the actual text the user is typing, plus the user interface language, and -- of course -- any lang= or xml:lang= attributes specified in the HTML. Ergo, the logic should be left up to the browser. On Thu, 12 Feb 2009, Kristof Zelechovski wrote: The language attribute can be changed at run time if needed. It requires an additional event that can be called langmismatch. Of course, a more traditional selector is also a solution. If the site is primary English, with Hebrew fragments here and there, it is not much harm that the fragments are considered spelling errors (although, in the case of English/Hebrew bilingualism, it is unlikely because the character set is different). In short, the user agent is allowed to use whatever AI it is equipped with. Markup for German AND English submissions at the same time, as per your request: LABEL LANG=de Inhalt: TEXTAREA NAME=INHALT /TEXTAREA /LABEL LABEL LANG=de Contents: TEXTAREA NAME=CONTENTS /TEXTAREA /LABEL On Thu, 12 Feb 2009, Bil Corry wrote: In my case, we have a single field, bug description that may contain both English and German. And in some cases, even a pure German bug report may reference the English form fields, such as: Legen Sie City vor Postal Code In that case, there is no way for a UA or Server to auto-determine the language, even if you're aware the user speaks both German and English. My suggestion is to leave the lang attribute out of the spec, and let the UA handle it as it wants. On Thu, 12 Feb 2009, K�~Yištof Želechovski wrote: Having interjected words marked as spelling errors is not a failure. The same phenomenon occurs with proper names and you cannot help that. The UI you described is inconsistent and it should be fixed. The control for German should be labeled Fehlerbeſchreibung or whatever. On Thu, 12 Feb 2009, Kristof Zelechovski wrote: I do not know much about UI standards but the rule that the answer
Re: [whatwg] The iframe element and sandboxing ideas
(Please pick one mailing list when replying, so as to reduce cross-posting.) On Thu, 22 May 2008, Martin Atkins wrote: * I've added a sandbox= attribute to iframe, which by default disables a number of features and takes a space-separated list of features to re-enable: Unless I'm missing something, this attribute is useless in practice because legacy browsers will not impose the restrictions. This means that as long as legacy browsers exist (i.e. forever) server-side filtering must still be employed to duplicate the effects of the sandbox. One alternative would be to use a different element name so that fallback content can be provided for legacy browsers. In the short term, this is likely to be something like this: sandbox src=/comments/blah iframe src=/comments/blah?do-security-filtering=1/iframe /sandbox Once a large percentage of browsers support sandbox authors can start to be less accommodating with their fallback content, either by filtering out HTML tags entirely (which I'd assume is easier than just filtering out script) or at the extreme just setting the fallback content to be Your browser is not supported. One can just do: iframe sandbox src=/comments/blah?do-security-filtering=1/iframe The sandbox feature just provides one more level of defence in depth, and is not intended to be a complete security solution. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The iframe element and sandboxing ideas
(Please pick one mailing list when replying, so as to reduce cross-posting.) On Thu, 22 May 2008, Boris Zbarsky wrote: Ian Hickson wrote: - by default, content in sandboxed browsing contexts, and any browsing contexts nested in them How do those nested browsing contexts come about, given that later you say: - content in those browsing contexts cannot create new browsing contexts or open modal dialogs or alerts ? My summary was under-precise, my apologies. The spec itself seems to be unambiguous here, though let me know if I missed anything. have a unique origin (independent of the origin of their URI); this can be overriden using the allow-same-origin keyword So the parent page cannot script the contents of the iframe by default, right? Correct. - by default, script in those browsing contexts cannot run; this can be overriden using the allow-scripts keyword What happens if the parent page sets window.location to a javascript: URI on the sandbox iframe? Does the script run? If so, in which browsing context? If the allow-same-origin flag is not set, the javascript: doesn't run, as cross-orgin javascript: execution is blocked. If the allow-scripts flag is not set, uh, *fixes error in the spec*. Ok, if the allow-scripts flag is not set, then javascript: doesn't run, as javascript execution is blocked in sandboxed browsing contexts. causes the iframe to size vertically to the bounding box of the contents, and horizontally to the width of the container I assume that the bounding box is computed after setting the width? No need to assume. :-) The spec text is at: http://www.whatwg.org/specs/web-apps/current-work/#attr-iframe-seamless Please do let me know if that is suboptimal. and the style sheets that apply to the iframe must also apply to the contents. But the ' ' and '' combinators don't cross the iframe boundary, right? It's as if the style sheets were imported directly by the inner frame. This is all HIGHLY EXPERIMENTAL. I am looking for feedback on the general approaches taken. As someone else pointed out, this doesn't seem like it would be usable without some UA sniffing or something, as things stand. Indeed. If someone can come up with a way of making this work in legacy UAs, I'd certainly be happy to change the spec to do that. There are various things that this doesn't address yet; e.g. there's no way to force (or even allow) a non-seamless iframe to open links in the parent window. This could be an @sandbox keyword value. Indeed. This attribute would take a string which would then be interpreted as the source document markup of an HTML document, much like the above This seems very prone to security issues (injection of the closing quote in the content) to me... The base64 approach is nice in that you can't shoot yourself in the foot with it. You would only have to escape two characters ( and , and in fact only the is needed to be safe). Base64 would indeed be safer. (Right now it's the only option, as I haven't introduced doc='' yet.) But escaping just one character seems like a pretty low bar. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The iframe element and sandboxing ideas
On Sat, 24 May 2008, Ojan Vafai wrote: So, the whole point of these is defining elements that are isolated from their surrounding context on different axes. Same origin iframes currently just give you CSS isolation. sandbox affords script isolation. seamless affords the ability to turn off the CSS isolation. Seems to me that we need a third property which controls event isolation. Currently events don't propagate in/out of iframes and event coordinates are all relative to the iframe's viewport (e.g. on mouse events). My first intuition was that seamless should also just propagate events and have mouse coordinate be relative to the parent browsing context. But I can think of cases where you would want to control the two separately. For example, if you are especially concerned about performance and don't want events in the parent browsing context to be handled by the iframe's contents. This is an interesting idea, but I think we should wait until we have more experience with sandbox= and seamless= before adding this feature. I am wary of adding too much at once. (We could add it later by having seamless=allow-events or some such.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] The iframe element and sandboxing ideas
On Fri, Feb 13, 2009 at 3:06 PM, Ian Hickson i...@hixie.ch wrote: Indeed. If someone can come up with a way of making this work in legacy UAs, I'd certainly be happy to change the spec to do that. Here's a suggestion. When requesting the contents of a sandboxed iframe, send an HTTP header that contains the sandbox policy: X-HTML-Sandbox-Policy: allow-forms, allow-scripts Servers can decide not to serve untrusted content if they don't see a sandbox policy they like. Adam
Re: [whatwg] Author control over media preloading/buffering
On Sat, Feb 14, 2009 at 12:00 AM, timeless timel...@gmail.com wrote: On Fri, Feb 13, 2009 at 12:55 AM, Robert O'Callahan rob...@ocallahan.org wrote: I don't really see a usecase for multiple priority levels. Do you have one? i've seen a lot of places of late which have multiple videos which are expected to play in some sort of sequence. Perhaps they should use script to add 'autobuffer' to the next video (or just play() it). Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
