Re: [whatwg] Author control over media preloading/buffering
2009/2/11 Robert O'Callahan rob...@ocallahan.org: So, how about adding an autobuffer attribute, which instructs the browser that the user will probably play the video and as much data as possible should be pre-downloaded? By default (when the attribute is not present) the browser would be expected to pause the download after reaching HAVE_CURRENT_DATA if the media element is paused and not 'autoplay'. if i'm a mobile browser vendor (and I am), and if I expect to use Bluetooth to talk to a cell phone which has high bandwidth costs (and if you're using an n800/n810 tethered to a phone in Canada, this is true), then, i'm not sure I really want web pages to specify things quite like this. If we're going to suggest something like this, i'd prefer it to be something like flex= bufferpriority=1, bufferpriority=2, which establish a sort and inform the browser which videos are most important, and the browser can then choose to collect as many of them as it feels comfortable collecting, possibly to the point that having played the highest priority, it proceeds to buffer the next highest priority video. If there are two things w/ bufferpriority=2, then the browser is free to treat them equally, but having already played one, it would then favor the other. There should be a note indicating that browsers are likely to discount priority if there are too many things at a given level to buffer (equivalent to having a box set where 5 children have flex=200).
Re: [whatwg] Spellchecking mark III
The discussion on spellcheck= focused on two ideas; using spellcheck= mostly as specced here: http://damowmow.com/playground/spellcheck.txt ...and doing something with lang=. The idea of using lang= had problems that were pointed out by several people, most notably, the issue that the user's language doesn't always match the site's. I think this makes it inappropriate for this use. I have added spellcheck= to the spec. If there's anything in the feedback that I missed, please let me know. I read every e-mail but there didn't seem to be anything specific that I should comment on. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Spellchecking mark III
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. 2. Check the spelling of the passage (asits!) :0) 3. Say that the default behavior for BODY is on and the default behavior for INPUT[type=text] is off. 4. (I understand that it is implicit that this SHOULD indicate does not make tiny clients that do not have the resources non-compliant?) 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). Best regards, Chris
Re: [whatwg] Spellchecking mark III
Kristof Zelechovski wrote on 2/12/2009 6:24 AM: 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). 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? - Bil
Re: [whatwg] Spellchecking mark III
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. HTH, Chris
Re: [whatwg] Spellchecking mark III
On Thu, Feb 12, 2009 at 8:57 AM, Kristof Zelechovski giecr...@stegny.2a.pl wrote: The server has two ways of knowing the user's preferred language: the user's preferences and the browser settings, in that order. 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. 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. I don't understand what you mean here.
Re: [whatwg] Spellchecking mark III
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 HTH, Chris
Re: [whatwg] DOMTimeStamp binding
On Wed, 11 Feb 2009 15:03:01 -0800, Darin Adler da...@apple.com wrote: On Feb 11, 2009, at 12:14 PM, Kartikaya Gupta wrote: I updated to Safari 3.2 on Windows (which looks it also has WebKit 525.27.1) and you're right, it is now showing number instead of object. I guess this was changed not too long ago. So then my question is: why was it changed? No, this was not changed. I don't understand why you were getting that strange result, but WebKit has always shown number for this. I went back to old versions, including digging out a copy of Safari 2 and every version I tested yields a number. There was never any code that attempted to return anything except a number. Well, I don't know what to tell you. Latest version of Chrome is still giving me a Date object. I don't know what version of WebKit it's using. More to the point, there's also a false premise in the specification's claim that this should be a Date. The Date class in JavaScript boils down to a double for its internal representation; I believe that's by design and not just a detail of the WebKit implementation. So the claim that a number, also a double, can't handle the entire range of DOMTimestamp, but the Date class can is probably incorrect. Maybe someone can give a specific example with details of how this would go wrong I dont think there is any such example. The DOM 3 Core actually says that an integer type in ECMAScript is too small. The ECMA-262 spec doesn't say anything about an integer type; all numbers are doubles, so I have no idea what the DOM spec is referring to. However, note that section 15.9.1.1 of ECMA-262 does says that the valid range for a Date object is slightly smaller than that representable by a double (8,640,000,000,000,000 milliseconds on either side of epoch, instead of 9,007,199,254,740,991), so there is a slight difference between returning a number and returning a Date. However, in practice it's unlikely those scenarios will be hit. Cheers, kats
Re: [whatwg] DOMTimeStamp binding
On Thu, 12 Feb 2009 07:03:22 +0100, Simon Pieters sim...@opera.com wrote: On Wed, 11 Feb 2009 21:14:44 +0100, Kartikaya Gupta lists.weba...@stakface.com wrote: I updated to Safari 3.2 on Windows (which looks it also has WebKit 525.27.1) and you're right, it is now showing number instead of object. I guess this was changed not too long ago. So then my question is: why was it changed? And seeing as Opera, WebKit, and Gecko are in agreement now to return a number rather than a Date in ECMAScript, will the DOM 3 Core spec be updated? Or will this get rolled into Web DOM Core and/or HTML5? Right now Web DOM Core says: A DOMTimeStamp represents a number of milliseconds. typedef unsigned long long DOMTimeStamp; ...and then refers to WebIDL for what that means to ECMAScript. It seems to me the simplest approach would be to bind DOMTimeStamp to a number for ECMAScript (the typedef should then make it unnecessary to explicitly define in WebIDL), and create a new type to represent things that actually return Date objects like the HTMLInputElement.valueAsDate in HTML5. This is likely what I'll end up doing for our IDL files anyhow so that all the bindings get generated correctly. Cheers, kats
Re: [whatwg] DOMTimeStamp binding
On Thu, 12 Feb 2009 16:12:49 +0100, Kartikaya Gupta lists.weba...@stakface.com wrote: It seems to me the simplest approach would be to bind DOMTimeStamp to a number for ECMAScript (the typedef should then make it unnecessary to explicitly define in WebIDL), and create a new type to represent things that actually return Date objects like the HTMLInputElement.valueAsDate in HTML5. This is likely what I'll end up doing for our IDL files anyhow so that all the bindings get generated correctly. Oh yep, this seems like an issue for HTML5. Is there anything other than valueAsDate that should return a Date? Any suggestions for what I need to do in Web DOM Core? -- Simon Pieters Opera Software
Re: [whatwg] [html5] Rendering of interactive content
2009/2/11 Ian Hickson i...@hixie.ch
[...]
2) you depend on css3-ui, in CR stage, instead of becss, a very
early WD
BECSS is actually probably more stable than CSS3 UI at this point.
Why do you say so? Will CSS3 UI go back to Last Call or BECSS process to
Last Call in the near future? I'm not sure. In the mean time, CSS3 UI is
final, and waiting only for implementation.
CSS3 UI is very vague, and is going to need serious work before browsers
are able to actually implement it properly. A lot of the vendor feedback
at the time it was written was dismissed (e.g. it doesn't have a
particularly useful or comprehensive list of appearances).
Well, it is the *Basic* User Interface, that is, the bare minimum. All the
rest is Advanced UI, that I hope one day we will have.
3) you don't block the binding property: I don't expect that
applying an XBL binding on an element causes it to appear like a
span (because it gets almost no default CSS)
This is actually intentional. Experience with elements like fieldset
that have styles that aren't expressed in CSS is that you end up not
being able to restyle them properly if you desire. With 'binding' we'd
be able to knock out the whole default rendering (including weird
things with the children) in one go.
The fact is that binding it the best way to apply a set of event
handlers to an element. Having to tweak the computed style of a fieldset
in order to find what properties are actually set and reproduce them in
the binding, just to put a set of onchange handlers to lots of fieldset,
does not look optimal.
I don't understand why you would need to know what properties are set, or
what 'onchange' has to do with anything here.
html xmlns=http://www.w3.org/1999/xhtml;
head
xbl xmlns=http://www.w3.org/ns/xbl;
binding id=textboxes
handlershandler event=onchangewindow.alert(Hey! You changed my text
box!); /handler/handlers
/binding
/xbl
styleinput[type=text] { binding: url(#textboxes); }/style
/head
bodyforminput type=text value=Change me! //form/body
/html
At a first look, it just sets an onchange event handler to every
input[type=text]. Using the HTML5 approach to widgets presentation, you
would need to set the appearance to field on the bound element or it will
look much like a span
[...]
I mean that Firefox and Safari set the appearance property on the widget
element, and it is visible from outside, and dynamically changeable at
run time. The binding property instead contains an opaque and UA
specific value, that is not intended to be changed from JS (to switch
back and forth between widget types)
I expect we'll define actual values for 'binding' in due course; that's
mostly waiting on XBL2 getting implemented. I don't see why 'appearance'
would work better with JS than 'binding'.
Ah ok. I thought you wanted to leave that to be implementation dependent.
This is completely different.
[...]
We'll probably change that to just use keywords in due course.
So what should be the difference between appearance: field and binding:
field ?
[...]
It's a guide to Web browser vendors who wish to render things in a
commonly accepted way.
I think that section is for
- implementors of new UAs, that don't need to reverse engineer the
competitor products in order to find the defaults
Right.
- authors, that in this way know what to expect from the various UA with
less testing, that sometimes is also impossible, eg. you cannot test the
rendering of a mobile phone if you don't have a mobile phone
Having somewhere written that hyperlinks should be blue, allows you to
style
the background-color to anything but blue.
The section is not really for authors (though I suppose authors might find
it interesting, in the same way they might find the parser section
interesting).
[...]
Authors should act as if the default style sheet is something sensible but
they don't know what. (Because that is in fact what the situation is, once
you consider user style sheets.)
That is, the rule for authors is not just act as the UA default style sheet
was not present, but also act as if it was completely undefined or defined
to something weird, so explicitily write it every time it may be dangerous,
like for :link.
That's a completely different point of view. Thank you for clarifications,
I'll write div { display:block; } and :link { color:blue;
background-color:transparent;} in all my style sheets from now on.
Giovanni
Re: [whatwg] Spellchecking mark III
Kristof Zelechovski wrote on 2/12/2009 9:05 AM: 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 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. - Bil
Re: [whatwg] Spellchecking mark III
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. Best regards, Chris -Original Message- From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Bil Corry Sent: Thursday, February 12, 2009 5:05 PM To: wha...@whatwg.org Subject: Re: [whatwg] Spellchecking mark III Kristof Zelechovski wrote on 2/12/2009 9:05 AM: 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 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. - Bil
Re: [whatwg] False orthogonal nature :read-only and :disabled in WF2
Either I am rather confused or there are some misunderstandings still. Some observations: Ian Hickson wrote: Having them be orthogonal is far more useful to authors. For example, imagine the following stylesheet: And I've made HTML5 say that :read-write doesn't apply to disabled controls. (1) If :read-write does not apply to disabled controls, :read-only does (since it applies to all other html elements - meaning they are mutually exclusive). Hence :disabled implies :read-only (not vice versa for the record) and hence :disabled and :read-only are not orthogonal. The spec now says :read-write does not apply to input elements that do NOT have the readonly attribute specified AND that are NOT disabled, or in other words (by mutual exclusivity), :read-only applies to input elements that have the readonly attribute specified OR are disabled. Grtz, Rikkert Koppes
Re: [whatwg] defer on style, depends
Garrett Smith wrote: I would be fine with a way to flag scripts with that information, though there is a catch-22: if you flag such a script and it DOES depend on style information, then existing UAs will get it right and any UA implementing the new spec will get it wrong. If the page does what it is designed to do, and that the design is flawed, the page would be broken by design. Designing things to be broken would be wrong. My point is that if no UAs implement the new stuff it's easy to make such a mistake, and then UAs that _do_ implement it will show your page not as you intended. In other words, widespread adoption of this in authoring before implementation would actually raise a bar to implementation, since it raises the chances that implementing the feature will break sites. Hence the catch-22 mention above. 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). Are you proposing HTML allow that? That's one possible solution to the issue of starting stylesheet loads as late as possible, yes. It's not a great one a priori, but has the benefit of good compat with existing UAs (which you said was a priority for you). Not that I think you are wrong, but that statement ought to be backed up by some tests. You mean tests showing that current UAs allow link rel=stylesheet at the end of body? No, just observing that the problem could have been avoided with a depends= attribute, if only such attribute had existed c2000, and having scripts wait only when depends is set. I like this design. That's nice, but the question is where we can go now given the current situation, not the one that existed 10 years ago. An independent attribute on a link says that a browser does not need to wait for that resource to finish loading before it loads other resources (like loading a script). When the parser parses that independent attribute, it sets a flag for the browser go ahead and download and run any subsequent script. That doesn't work for today's browsers, though, just like flagging the script doesn't. Or am I missing something? You got it. It doesn't work for today's browsers. However, it isn't guaranteed *not* to work by any standard. In fact, browsers behave differently on the matter. Could this new feature result in breaking code in older browsers? No, but my point is that if you're concerned about solutions due to their impact on old browsers, then this solution has the same impact as all the things Ian has proposed... You say that stylesheets do not block script loading. That may be true of Shiretoko 1.9.1, however, that is not what I see for Firefox 3.0. The example I posted shows that stylesheets hold up body content from rendering. If that content contains a script tag, the script will *not* load *or* run. I can tell you for a fact, having implemented this part of Gecko myself, that a stylesheet will prevent body content from _rendering_, but NOT from being parsed. It will furthermore not prevent scripts from loading, but _will_ prevent them from running. I can point you to the relevant code if desired. The following example shows this to be true: http://dhtmlkitchen.com/jstest/block/link-external.html This example demonstrates that pending script execution blocks parsing and hence script loading in Gecko 1.9.0. In fact, it says so right in the example. That's not the same thing as stylesheets blocking script loading. And yes, in Gecko 1.9.1 the speculative parser will likely kick off all the script loads while still waiting for the stylesheet in this case. The only explanation I have for this behavior is that the browser is waiting for the stylesheet to complete before it requests the script in the body. No, it's waiting for the head scripts to execute before parsing the body and requesting the script. Those scripts happen to be waiting for the stylesheet, but if you didn't have them there the script in the body would be loaded in parallel with the stylesheet. Heck, you don't even need the external script in head. The inline one would give you the same behavior. That is why it would be better for performance to have that script prefetched Something that UAs are working on anyway, with speculative parsing used to prefetch content. That's happening in at least Webkit and Gecko. What I said was true for all scripts. We do not differentiate between content in head and content in body in this regard. In Shiretoko 3.1, true, but in Firefox 3.1, the bottom script is not loaded. That has nothing to do with head vs body, as you could trivially test by moving those scripts around in your document. All that matters is the order of the script tags. However, external resources such as SCRIPT or IMG that appear in the BODY will not get requested by the browser until the page content renders. You mean until all the HTML
Re: [whatwg] Spellchecking mark III
Křištof Želechovski wrote on 2/12/2009 10:15 AM: The UI you described is inconsistent and it should be fixed. Inconsistent with which UI standard? - Bil
Re: [whatwg] Spellchecking mark III
I do not know much about UI standards but the rule that the answer should be formulated in the language of the question is rather straightforward. It is just common sense. Exceptions are questions like How is that in German?. Chris
Re: [whatwg] DOMTimeStamp binding
On Feb 12, 2009, at 7:08 AM, Kartikaya Gupta wrote: Latest version of Chrome is still giving me a Date object. I don't know what version of WebKit it's using. Chrome uses an entirely different JavaScript binding, not the standard WebKit one, so I'm not surprised that it’s exhibiting different behavior. -- Darin
Re: [whatwg] Spellchecking mark III
Kristof Zelechovski wrote on 2/12/2009 11:06 AM: I do not know much about UI standards but the rule that the answer should be formulated in the language of the question is rather straightforward. It is just common sense. Exceptions are questions like How is that in German?. No one can control the language a user will choose to use in a textarea, regardless of the label used to describe it. Providing a localized textarea for every language might increase the odds of the user using the language the server prefers, but there is no guarantee. And I'm unclear what problem that would ultimately solve. - Bil
Re: [whatwg] Fwd: [html5] Semantic elements and spec complexity
2009/2/11 Ian Hickson i...@hixie.ch: On Wed, 11 Feb 2009, David Gerard wrote: Think of tag-soupness as a feature, not a bug. Shudder in horror at what this implies. I don't think that's a particularly controversial position here. People in other mailing lists involved in the development of HTML5 might disagree. :-) It's definitely a feature, not a bug, in Wikitext - Wikipedia has many contributors who write great articles but basically can't work a computer otherwise. If it wasn't, Wikipedia would be written in immaculately nested XML ... and XML was expressly *not* designed for humans to write, but for machines to talk to each other. Whether it's a feature for HTML, well, I suspect the people who write parsers have a few choice words on the matter ;-) - d.
Re: [whatwg] Spellchecking mark III
The majority of users will answer the question in the language of the question, this is the normal reaction. Of course there is no guarantee but the odds of getting the expected result are high. Assuming that the user's input will actually be read by somebody, providing proper markup will help the readers to get something they are able to read. Chris
Re: [whatwg] DOMTimeStamp binding
* Kartikaya Gupta wrote: DOM 3 Core says this about DOMTimeStamp: For Java, DOMTimeStamp is bound to the long type. For ECMAScript, DOMTimeStamp is bound to the Date type because the range of the integer type is too small. The former WebAPI working group discussed this issue and found that the reasoning behind this was bogus and, taking into account deployed imple- mentations resolved, to change the binding to the Number type. DOM Level 3 Events does as much, along with pointing out the Group's intent to up- date DOM Level 3 Core accordingly (see the Changes appendix). -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [whatwg] Selectors Tests and :enabled
Ian Hickson wrote: On Wed, 11 Feb 2009, fantasai wrote: Given the state of current implementations and the fact that hidden input elements do have distinct enabled and disabled states, I don't understand the reasoning behind this change. http://twitter.com/WHATWG/status/1198455588 The idea was to match Selectors. ... I see this has now changed. I will update HTML5 in due course to match the new text in Selectors. (I'll also update my spec index to point to the dev.w3.org link instead of the /TR/ page so that I don't make this mistake again.) Ok. I'll ping you once we publish a new draft (which, hopefully, should be within a week or two). ~fantasai
Re: [whatwg] Script/parser interaction bug?
On Thu, 12 Feb 2009 06:55:18 + (UTC), Ian Hickson i...@hixie.ch wrote: Could you reannotate the above but with the script nesting level explicitly given at each step? Below is an updated annotation including all the script nesting level and parser pause flag changes. (Original annotation at http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2009-January/018289.html) - initially, script nesting level is zero, parser pause flag is false - tokenize/treebuild ext7.html until the first closing script tag is found (for the 7a.js script) - increment the script nesting level to 1 - the 7a.js script tag has a src attribute, so it gets set as the pending external script - decrement the script nesting level to zero - since the script nesting level is zero, set the parser pause flag to false (it was already false) - execute the pending external script (7a.js) (this clears the pending external script pointer) --- insert script src=ext7b.js/script into the input stream --- tokenize/treebuild the 7b.js script tag until the /script for 7b.js is found --- increment the script nesting level to 1 --- the 7b.js script tag has a src attribute, so it gets set as the pending external script --- decrement the script nesting level to zero --- since the script nesting level is zero, set the parser pause flag to false (it was already false) --- there is a pending external script (7b.js) but the tree construction stage is re-entrant, so set parser pause flag to true and return --- insert remaining document.write content from 7a.js into the input stream. since there is a pending external script, none of it gets tokenized/treebuilt - 7a.js finishes executing. at this point the script nesting level is zero and the parser pause flag is true - check again for a pending external script. there is one, 7b.js - execute the pending external script (7b.js) (this clears the pending external script pointer) --- throws - 7b.js finishes executing. at this point the script nesting level is zero and the parser pause flag is true - continue processing the input stream (this now has the contents of the document.write calls from 7a.js, line 2 onwards) - tokenize/treebuild the input stream until the /script at the bottom of 7a.js is encountered - increment the script nesting level to 1 - the script tag does not have a src attribute, so it gets executed --- insert the div into the input stream --- since the parser pause flag is true the div does NOT get tokenized/treebuilt --- run the line that sets .firstChild.data to PASS. since the div isn't in the DOM yet, this throws - the script written from 7a.js finishes executing. at this point the script nesting level is 1 and the parser pause flag is true - decrement the script nesting level to zero - since the script nesting level is zero, set the parser pause flag to false - continue processing the input stream (this now contains just the div tag with FAIL inside) - tokenize/treebuild the input stream, which adds the FAIL div to the DOM - done Cheers, kats
Re: [whatwg] Author control over media preloading/buffering
On Thu, Feb 12, 2009 at 10:13 PM, timeless timel...@gmail.com wrote: 2009/2/11 Robert O'Callahan rob...@ocallahan.org: So, how about adding an autobuffer attribute, which instructs the browser that the user will probably play the video and as much data as possible should be pre-downloaded? By default (when the attribute is not present) the browser would be expected to pause the download after reaching HAVE_CURRENT_DATA if the media element is paused and not 'autoplay'. if i'm a mobile browser vendor (and I am), and if I expect to use Bluetooth to talk to a cell phone which has high bandwidth costs (and if you're using an n800/n810 tethered to a phone in Canada, this is true), then, i'm not sure I really want web pages to specify things quite like this. Then you can have the browser ignore autobuffer. Problem solved. bufferpriority=1, bufferpriority=2, which establish a sort and inform the browser which videos are most important, and the browser can then choose to collect as many of them as it feels comfortable collecting, possibly to the point that having played the highest priority, it proceeds to buffer the next highest priority video. If there are two things w/ bufferpriority=2, then the browser is free to treat them equally, but having already played one, it would then favor the other. I don't really see a usecase for multiple priority levels. Do you have one? 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]
Re: [whatwg] HTML5 fo ecommerce
On Fri, 23 Jan 2009, Mynthon wrote: I have some questions about html. I really like new section / tag and its possibility to have its own hx / structure. Dont like mixing hx / levels but thats BTW. I have strange feeling that in next 5 years not only blogs will be available on the web but also some e-commerce pages (online shop, auctions). Also some new applications. Now i cant figure out how to use html5 for those sites. On my companys page there are no articles and sections. There are products and product lists. Isnt it wrong to use article section h1product1/h1 some data /section section h1product2/h1 some data /section section h1product3/h1 some data /section /article while it wil be misleading screen readers? For users without disabilities there is no problem but for eg. blind peple? Calling product list an article is... hmmm... wrong. Yup. Don't do it. :-) The same goes for pages with advertisements and announcements, e-mail web frontends, forums, and every other page that is not blog or newspage. If there are new tags for blogs (article /, section /, audio /, video /) are there plans for tags usable for other pages (product /, productlist /, price /, subject /, thread /, announcement /, review / etc.) There are no plans for this in HTML5 (though maybe in HTML6). If you have a (product) list, then we have ul and ol. Threads (like in forums) can be represented with nested article elements; that's part of what that element is for -- a post is considered an article, in fact a forum post is the very first example in the spec. Something like: product h1New book/h1 pby Chris Grabowski/p pold price: span5usd/span/p pstrongNow only:/strong price3.99usd/price/p pThis is description of product .../p /product Will be very cool for me and many other. I think using section for this is fine, along with some classes: section class=product header h1New book/h1 pby Chris Grabowsky/p /header pOld price: span5 USD/span/p pstrongNow only:/strong span class=price3.99USD/span/p pThis is description of product .../p /section -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 5.7.6 The application cache selection algorithm
On Thu, 29 Jan 2009, Michael Nordman wrote: Note that the document-is-markup flag will likely go away, and be replaced by just checking to see if there is a manifest (as it was before). The reason this particular thing might change is that I checked it in yesterday and this morning one of the Apple guys complained to me on IRC about it, pointing out it was a change from the earlier text and that he thought the earlier text made more sense. :-) The behavior of HTML resources listed in the manifest but not having a manifest= attribute would be very different if this change is adopted. Unless somebody has learned something concrete from experience with this system to indicate that this change is called for... probably should be backed out. I can imagine cases where this change would be difficult to deal with. For example a static HTML page could not be incorporated into more than one appcache. If you have a system that provides an appcache per user (say by virtue of dynamically generated top level pages containing manifest attributes), your only option would be to dynamically generate all HTML resources within that cache to contain the appropiate manifest attribute. I've changed it so that XML and HTML files that don't have an explicit manifest will get fetched from an appcache if there is one from the same origin. (If someone _adds_ a manifest, then the cache will get updated with that new URL, and if the user goes back to that page, then it'll fail to load from the apocache since it is now foreign.) HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] swapCache algorithm changes
On Fri, 30 Jan 2009, Alexey Proskuryakov wrote: I've noticed that swapCache() now raises an exception if the cache's application cache group is marked as obsolete. Previously, this resulted in the document being unassociated from the cache. Why such a change? It seems arbitrary - the previous behavior made good sense. I've switched it back to the old unassociating behavior. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Methods defined for one document called after that document is no longer the one being displayed
On Sat, 31 Jan 2009, Boris Zbarsky wrote: Ian Hickson wrote: I haven't mentioned the 'this' behavior, so right now |this !=== window|, which breaks the invariant that there is no way to actually get hold of a reference to the Window object itself (as opposed to the outer WindowProxy object that forwards to the inner Window object). This requirement would be a violation of ECMAScript 3.1, so if we could get that changed in ES3.1, that would be great. Failing that, it should probably be in the WebIDL JavaScript binding section. As I recall, in Gecko the keyword |this| evaluates to the outer window. I'm not sure what happens to the implicit |this| that's computed when defining a global function, say. The reason for this setup was precisely to prevent script from getting a handle to the inner Window. Since we do security checks for cross-site scripting in the outer Window, any ability to pass inner Windows cross-site would be an automatic security hole. The setup as it exists right now allows scripts that run within a single window and never explicitly touch Window objects to not have to perform security checks on every property access. You might want to double-check with Blake Kaplan, Brendan Eich, or Johnny Stenback on the above, as well as on how this fits in with ECMAScript 3.1. I seem to recall something about that going by in the bugs when this was being worked on, but Brendan is more likely to recall the details than I am to be able to find them... I've pinged Brendan about this, but on the short term, I've put the requirement in HTML5, so that we don't lose it. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Semi-transparent content models
On Mon, 2 Feb 2009, Lachlan Hunt wrote: The spec defines the semi-transparent content model, but this is no longer used for any elements. Please remove this from the spec. http://www.whatwg.org/specs/web-apps/current-work/#transparent-content-models Done. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] 5.12.3.7 Link type help
On Tue, 3 Feb 2009, Philipp Kempgen wrote: ---cut--- 5.12.3.7 Link type help The help keyword may be used with link, a, and area elements. For link elements, it creates a hyperlink. ---cut--- Shouldn't that read For *a* elements, it creates a hyperlink.? On Tue, 3 Feb 2009, Giovanni Campagna wrote: a elements are always hyperlinks, link can be hyperlinks or resources. So it only makes sense for the link element to be explicitly marked like this. What Giovanni said. :-) Hopefully this is more obvious if you look at the other link types as well. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] List Headers
On Wed, 4 Feb 2009, Lachlan Hunt wrote: You can do this in HTML5, using figure and legend: figure legendA header for the list/legend ul liList item/li liList item/li liList item/li /ul /figure Since figure is a sectioning root, a heading element could also be used here and it wouldn't affect the outline. Please add an example of this use case to the spec. I considered this, but frankly ol, ul, and figure already have a whole bunch of examples, and it turns out li already has an example of a list in a figure element. On Thu, 5 Feb 2009, Markus Ernst wrote: A different use case in the same problem field: Often you have lists that are actually part of a paragraph, but cannot be correctly associated with the paragraph: pText before .../p pThere are lots of fruits available, e.g.:/p ul liApples/li liPears/li /ul pMore Text.../p More appropriate markup for this could be achieved with the LH suggestion: pText before .../p ul lhThere are lots of fruits available, e.g.:/lh liApples/li liPears/li /ul pMore Text.../p Anyway I would consider it even more appropriate to allow the list inside a paragraph: pText before .../p pThere are lots of fruits available, e.g.: ul liApples/li liPears/li /ul /p pMore Text.../p But I admit I have no idea what other problems this could cause. We had this in the spec originally, but we dropped it due to a variety of issues (it made life harder for editors, it didn't work in text/html even when it looked like it did, people got confused...). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Methods defined for one document called after that document is no longer the one being displayed
On Thu, Feb 12, 2009 at 7:15 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 31 Jan 2009, Boris Zbarsky wrote: Ian Hickson wrote: I haven't mentioned the 'this' behavior, so right now |this !=== window|, which breaks the invariant that there is no way to actually get hold of a reference to the Window object itself (as opposed to the outer WindowProxy object that forwards to the inner Window object). This requirement would be a violation of ECMAScript 3.1, so if we could get that changed in ES3.1, that would be great. Failing that, it should probably be in the WebIDL JavaScript binding section. As I recall, in Gecko the keyword |this| evaluates to the outer window. I'm not sure what happens to the implicit |this| that's computed when defining a global function, say. The reason for this setup was precisely to prevent script from getting a handle to the inner Window. Since we do security checks for cross-site scripting in the outer Window, any ability to pass inner Windows cross-site would be an automatic security hole. The setup as it exists right now allows scripts that run within a single window and never explicitly touch Window objects to not have to perform security checks on every property access. You might want to double-check with Blake Kaplan, Brendan Eich, or Johnny Stenback on the above, as well as on how this fits in with ECMAScript 3.1. I seem to recall something about that going by in the bugs when this was being worked on, but Brendan is more likely to recall the details than I am to be able to find them... I've pinged Brendan about this, but on the short term, I've put the requirement in HTML5, so that we don't lose it. cc'ing a couple of people that are intimately familiar with how the split-window implementation works in gecko. / Jonas
