Re: [whatwg] video await a stable state in resource selection (Was: Race condition in media load algorithm)
On Mon, 09 Aug 2010 18:35:47 +0200, Boris Zbarsky bzbar...@mit.edu wrote:
On 8/9/10 12:14 PM, Philip Jägenstedt wrote:
Why? Maybe if I understood what we're trying to accomplish with the
synchronous section bit here I'd have a better idea of how it should
work...
The general idea of waiting is that since the following steps of the
resource selection algorithm inspects video elements src attribute and
source element children, those should be in a consistent state before
the checking is done.
OK, but then why are we not imposing such a requirement for the case
when the video is being created by the parser?
Because the parser can't create a state which the algorithm doesn't
handle. It always first inserts the video element, then the source
elements in the order they should be evaluated. The algorithm is written
in such a way that the overall result is the same regardless of whether it
is invoked/continued on each inserted source element or after the video
element is closed. However, scripts can see the state at any point, which
is why it needs to be the same in all browsers.
body
script
var v = document.createElement('video');
var exts=[webm, mp4];
exts.forEach(function(ext) {
var s = document.createElement('source');
v.appendChild(s);
s.src = foo.+ext;
s.type = video/+ext;
document.body.appendChild(v);
});
/script
Unless we wait until the script has finished before running the
synchronous section, no source at all will be selected
Because changes to the set of source elements do not restart the
resource selection algorithm, right? Why don't they, exactly? That
seems broken to me, from the POV of how the rest of the DOM generally
works (except as required by backward compatibility considerations)...
The resource selection is only started once, typically when the src
attribute is set (by parser or script) or when the first source element is
inserted. If it ends up in step 21 waiting, inserting another source
element may cause it to continue at step 22.
Restarting the algorithm on any modification of source elements would mean
retrying sources that have previously failed due to network errors or
incorrect MIME type again and again, wasting network resources. Instead,
the algorithm just keeps it state and waits for more source elements to
try.
However, as long as the same is true in all browsers this seems
easy to fix in the script itself, just a bit non-obvious.
But why are we purposefully introducing hysteresis into the DOM? It'd
make a lot more sense to me to not have hysteresis here if at all
possible.
I'm not sure what you mean by hysteresis, but guess you mean the somewhat
ridiculous amount of state one has to keep track of? I think the root
cause of this is that if a source fails due to network errors (i.e.
asynchronously after the resource selection algorithm has returned) then
we want to try the next one. If we threw this out the window, then one
could define the algorithm in such a way that it only needs to be run
synchronously once and then be done. I could live with such a solution,
but I don't think it's the best one.
I'm trying to come up with a big scary problem that would motivate the
complexity of await a stable state, but I can't see it. I doubt
StackOverflow would be flooded by issues caused by quirks as the one
above.
It actually probably would, if if we actually had such a quirk.
OK, let's not debate this point :)
1. Remove the await a stable state concept and just continue running
the steps that follow it. (This is what Opera does now when resource
selection is triggered by the parser, as I have no idea how long to wait
otherwise.)
I have a really hard time believing that you trigger resource selection
when the video is inserted into the document and don't retrigger it
afterward, given that... do you?
2. Instead of calling the resource fetch algorithm in step 5/9
There doesn't seem to be such a step...
3. In step 21, instead of waiting forever, just return and let inserting
a source element cause it to continue at step 22.
Again, the numbering seems to be off.
These are steps in the resource selection algorithm, not in the resource
fetch algorithm.
Since this doesn't introduce any new concepts to the spec, I assume it
would be implementable in Gecko?
Given the premise, presumably. But the resulting behavior still seems
broken in the parser case; see above
No, in the parser case I am very confident that it will work just fine, as
this is almost exactly what we already do. It's only in the case of
scripts that there's a risk of introducing new quirks. However, at this
point it's likely that some scripts are already doing things in the
wrong order, so perhaps it's too late to make the change I am suggesting.
Mozilla is implementing this now. How are you interpreting await a stable
state when the resource selection algorithm is triggered by the parser?
Will
Re: [whatwg] select element should have a required attribute
On 08/10/2010 07:09 AM, Garrett Smith wrote: Many times you want the user to make an explicit choice, rather than just leaving whatever was already selected. What many websites do is: labelChoose an option: select option/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select /label The first option should be selected, resulting in the select having value=. If `required` is specified, and the user selects an empty option (the first option in the list) and submits the form, what do you think should happen? Like for input or textarea, if select.value is the empty string, the select element suffers for being missing. Or select option value=Choose an option:/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select What should happen if the SELECT has `required`? ditto -- Mounir
Re: [whatwg] select element should have a required attribute
On Tue, 2010-08-10 at 11:35 +0200, Mounir Lamouri wrote: On 08/10/2010 07:09 AM, Garrett Smith wrote: Many times you want the user to make an explicit choice, rather than just leaving whatever was already selected. What many websites do is: labelChoose an option: select option/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select /label The first option should be selected, resulting in the select having value=. If `required` is specified, and the user selects an empty option (the first option in the list) and submits the form, what do you think should happen? Like for input or textarea, if select.value is the empty string, the select element suffers for being missing. Or select option value=Choose an option:/option optionvalue 1/option optionvalue 2/option optionvalue 3/option /select What should happen if the SELECT has `required`? ditto -- Mounir If you receive an empty text box then a required element works to validate against empty input. As you produce the input for the select list, it's pretty stupid to say that it shouldn't have an empty string for a value because you put it there. I can think of lots of places where an empty string is in-fact very useful for a select element, such as filters on search results forms, but if there's any places that I want a value, then I don't leave empty elements lying around. If you need to do that, then maybe use radio buttons instead. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On Tue, 10 Aug 2010 01:34:02 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
On Tue, Aug 10, 2010 at 12:04 AM, Philip Jägenstedt
phil...@opera.comwrote:
On Sat, 07 Aug 2010 09:57:39 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com wrote:
Hi Philip,
On Sat, Aug 7, 2010 at 1:50 AM, Philip Jägenstedt phil...@opera.com
wrote:
I'm not sure of the best solution. I'd quite like the ability to use
arbitrary voices, e.g. to use the names/initials of the speaker rather
than
a number, or to use e.g. shouting in combination with CSS :before {
content 'Shouting: ' } or similar to adapt the display for different
audiences (accessibility, basically).
I agree. I think we can go back to usingspan and @class and @id and
that
would solve it all.
I guess this is in support of Henri's proposal of parsing the cue using
the
HTML fragment parser (same as innerHTML)? That would be easy to
implement,
but how do we then mark up speakers? Using span
class=narrator/span
around each cue is very verbose. HTML isn't very good for marking up
dialog,
which is quite a limitation when dealing with subtitles...
I actually think that the span @class mechanism is much more flexible
than
what we have in WebSRT right now. If we want multiple speakers to be
able to
speak in the same subtitle, then that's not possible in WebSRT. It's a
little more verbose in HTML, but not massively.
We might be able to add a special markup similar to the [timestamp]
markup
that Hixie introduced for Karaoke. This is beyond the innerHTML parser
and I
am not sure if it breaks it. But if it doesn't, then maybe we can also
introduce a [voice] marker to be used similarly?
An HTML parser parsing 1 or 00:01:30 will produce text nodes 1 and
00:01:30. Without having read the HTML parsing algorithm I guess that
elements need to begin with a letter or similar. So, it's not possible to
(ab)use the HTML parser to handle inner timestamps of numerical voices,
we'd have to replace those with something else, probably more verbose.
* there is no version number on the format, thus it will be difficult
to
introduce future changes.
I think we shouldn't have a version number, for the same reason that
CSS
and HTML don't really have versions. If we evolve the WebSRT spec, it
should
be in a backwards-compatible way.
CSS and HTML are structured formats where you ignore things that you
cannot
interpret. But the parsing is fixed and extensions play within this
parsing
framework. I have my doubts that is possible with WebSRT. Already one
extension that we are discussion here will break parsing: the
introduction
of structured headers. Because there is no structured way of extending
WebSRT, I believe the best way to communicate whether it is backwards
compatible is through a version number. We can change the minor
versions
if
the compatibility is not broken - it communicates though what features
are
being used - and we can change the major version of compatibility is
broken.
Similarly, I think that the WebSRT parser should be designed to ignore
things that it doesn't recognize, in particular unknown voices (if we
keep
those). Requiring parsers to fail when the version number is increased
oh, you misunderstood me: I am not saying that parser have to fail - it's
good if they don't. But I am saying that if we make a change to the
specification that is not backwards compatible with the previous one and
will thus invariably break parsers, we have to notify parsers somehow
such
that if they get parse errors they can e.g. notify the user that this is
a
new version of the WebSRT format which their software doesn't support
yet.
A browser won't bother their users by saying hey, there was something in
this page I didn't understand, as users won't know what to do to fix it.
Think for example about the case where we had a requirement that a double
newline starts a new cue, but now we want to introduce a means where the
double newline is escaped and can be made part of a cue.
Other formats keep track of their version, such as MS Word files. It is
to
be hoped that most new features can be introduced without breaking
backwards
compatibility and we can write the parsing requirements such that certain
things will be ignored, but in and of itself, WebSRT doesn't provide for
this extensibility. Right now, there is for example extensibility with
the
WebSRT settings parsing (that's the stuff behind the timestamps) where
further setting:value settings can be introduced. But for example the
introduction of new cue identifiers (that's the marker at the start
of
a cue) would be difficult without a version string, since anything that
doesn't match the given list will just be parsed as cue-internal tag and
thus end up as part of the cue text where plain text parsing is used.
The bug I filed suggested allowing arbitrary voices, to simplify the
parser and to make future extensions possible.
Re: [whatwg] input type=location proposals
On Mon, 2010-08-09 at 23:45 +, Ian Hickson wrote: On Fri, 18 Jun 2010, Eitan Adler wrote: Two separate use cases 1) For entry of locations into something like Google Maps or MapQuest. In this case the form should look as it does now (a text box) but browsers would be able to assist you in entering locations like it can for for emails. 2) For entry of Lat/Long coordinates which can be entered either manually or with some kind of map like interface. These are two separate proposals and I both could co-exist one as type=location and the other as type=gps Could you give some examples of sites that would use this, and examples of how they're working around the lack of this feature currently? Any CRM with clients/suppliers/partners/people might want to define a GPS location for a building/office/destination. Currently they usually use a text input. On Sun, 20 Jun 2010, Eitan Adler wrote: For type=gps I was thinking something like the following: 1) type=gps results in a (double?) text box which takes a latitude and a longitude 2a) there is some css option that tells the text box to act like a map instead. 2b) If the css option is on there is also some method of requesting a map source this source could be any existing map provider Then again now that I think about it some more I don't see this working out too well. Does this solve a problem that two type=number controls wouldn't solve? type=url and type=email are here for what? We could all use type=text for everything. On Fri, 25 Jun 2010, Ashley Sheridan wrote: I think it's quite a fringe case. What about things that are more used: * type=number - a browser could aid input with some sort of spinner * type=price - a browser could use the locale to select a monetary format, or at least display the amount in the locale format specified by the document itself These are just a couple that I think would potentially be more useful than type=location, as I see their use quite a lot. The price one is probably more reserved to CMS's and auction sites, but these are fairly common enough in use I feel. Number could be used for a whole plethora of cases, such as a quantity amount in a shopping cart, an age field in a form, or anything else where you might need a number that wouldn't necessarily be sensible to use a type=range for. Well we have type=number. I don't know that type=price would be _that_ useful; mostly prices are output, not input. An invoice app would want price input for products or for specific invoice adjustments.
Re: [whatwg] select element should have a required attribute
I'm not sure what the right solution is, but here's my two cents. I consider it highly desirable to have some way to differentiate between SELECT values explicitly selected by the user and values that were selected by default and unchanged by the user. For that reason I've commonly included Choose one options: option value=Choose one/option I can think of lots of places where an empty string is in-fact very useful for a select element, such as filters on search results forms I also see Ashley's point because I've done that too. E.g. select name=gender option value=Doesn't matter/option option value=MMale/option option value=FFemale/option /select However, I think in those cases I could substitute some other value for empty string (e.g. * in this case) that would communicate the necessary information to the server-side logic. If you need to do that, then maybe use radio buttons instead. I don't see that as a practical alternative in many cases: radio buttons take up a lot more space. Even in the gender example I gave, using radio buttons instead would have a detrimental effect on the layout of the particular form I took the example from. And when there are more options it makes a huge difference. Radio buttons could be very unwieldy where a SELECT works well. Jesse - Original Message - Date: Tue, 10 Aug 2010 10:35:53 +0100 From: Ashley Sheridan a...@ashleysheridan.co.uk If you receive an empty text box then a required element works to validate against empty input. As you produce the input for the select list, it's pretty stupid to say that it shouldn't have an empty string for a value because you put it there. I can think of lots of places where an empty string is in-fact very useful for a select element, such as filters on search results forms, but if there's any places that I want a value, then I don't leave empty elements lying around. If you need to do that, then maybe use radio buttons instead. Thanks, Ash http://www.ashleysheridan.co.uk
Re: [whatwg] HTML5 video source dimensions and bitrate
On Mon, Aug 9, 2010 at 8:05 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Have you looked at the @media attribute? I would suggest to put them there. As that's not currently specified in media queries, you might want to demonstrate how it could work and make a proposal to extend the media queries. I thought about suggesting something like bitrate a bandwidth to media queries. The syntax would look something like: video width=720 source src=video-480.mp4 media=(width:480px) and (min-bitrate:2mbps) source src=video-720.mp4 media=(width:720px) and (min-bitrate:4mbps) source src=video-1080.mp4 media=(width:1080px) and (min-bitrate:20mbps) /video The problem is that the user agent would have to then know what bitrate can be supported between you and that source. User agents don't currently keep track of this information (so far as I'm aware), and even if they did, it's highly variable based on your location, the website you're visiting, etc. Additionally, while media queries do help content producers specify which resource would be selected for a device under ideal circumstances, it doesn't really allow for degradation. However, if you look at what's out there today, it's pretty common to allow users to switch to a degraded experience as needed. I can think of a few solutions that might make sense here: * Allow source sub-elements / groupings and provide a call to switch between elements of a group. Ideally, this would look something like: video width=720px sourcegroup type=video/mp4 media=screen and (device-aspect-ratio: 16/9) source src=video-1080.mp4 meta=width:1920px;height:1080px;bitrate:20mbps; source src=video-720.mp4 meta=width:1280px;height:720px;bitrate:4mbps; /sourcegroup sourcegroup type=video/mp4 media=screen and (device-aspect-ratio: 4/3) source src=video-480.mp4 meta=width:640px;height:480px;bitrate:2mbps; /sourcegroup sourcegroup type=video/ogv source src=video-480.ogv meta=width:640px;height:480px;bitrate:2mbps; source src=video-720.ogv meta=width:1280px;height:720px;bitrate:4mbps; source src=video-1080.ogv meta=width:1920px;height:1080px;bitrate:20mbps; /sourcegroup /video * Have user agents keep track of information about dropped frames. Publishers could then list multiple valid sources in order of rank. When the dropped frame rate increased, either the user agent or a bit of JavaScript could remove that source and re-run the resource selection algorithm. On Mon, Aug 9, 2010 at 8:23 PM, Chris Double chris.dou...@double.co.nz wrote: Since your player is already JavaScript is having a JS object holding the URL, dimensions and bitrate not an option? This is probably what we'll end up doing for now, however, it would be nice to be able to parse this data out of the video tag. How are you working out the current playback rate to decide when to switch to a different bitrate version? Is having an attribute of the media element that contains this information useful? It would be useful for the initial selection. See http://www.longtailvideo.com/support/jw-player/jw-player-for-flash-v4/12208/video-delivery-rtmp-streaming#dynamicstreaming. Best, Zach -- Zachary Ozer Developer, LongTail Video w: longtailvideo.com • e: z...@longtailvideo.com • p: 212.244.0140 • f: 212.656.1335 JW Player | Bits on the Run | AdSolution
Re: [whatwg] video await a stable state in resource selection (Was: Race condition in media load algorithm)
On 8/10/10 4:40 AM, Philip Jägenstedt wrote: Because the parser can't create a state which the algorithm doesn't handle. It always first inserts the video element, then the source elements in the order they should be evaluated. The algorithm is written in such a way that the overall result is the same regardless of whether it is invoked/continued on each inserted source element or after the video element is closed. Ah, the waiting state, etc? Why does the algorithm not just reevaluate any sources after the newly-inserted source instead? However, scripts can see the state at any point, which is why it needs to be the same in all browsers. I'm not sure which the state you mean here. Because changes to the set of source elements do not restart the resource selection algorithm, right? Why don't they, exactly? That seems broken to me, from the POV of how the rest of the DOM generally works (except as required by backward compatibility considerations)... The resource selection is only started once, typically when the src attribute is set (by parser or script) or when the first source element is inserted. If it ends up in step 21 waiting, inserting another source element may cause it to continue at step 22. Right, ok. Restarting the algorithm on any modification of source elements would mean retrying sources that have previously failed due to network errors or incorrect MIME type again and again, wasting network resources. Instead, the algorithm just keeps it state and waits for more source elements to try. Well, the problem is that it introduces hysteresis into the DOM. Why is this a smaller consideration than the other, in the edge case when someone inserts sources in reverse order and slowly (off the event loop)? That is, why do we only consider sources inserted after the |pointer| instead of all newly inserted sources? I'm not sure what you mean by hysteresis http://en.wikipedia.org/wiki/Hysteresis Specifically, that the state of the page depends not only on the current state of the DOM but also on the path in state space that the page took to get there. Or in other words, that inserting two source elements does different things depending on whether you do appendChild(a); appendChild(b) or appendChild(b); insertBefore(a, b), even though the resulting DOM is exactly the same. Or in your case, the fact that the ordering of the setAttribute and insertChild calls matters, say. Such situations, which introduce order-dependency on DOM operations, are wonderful sources of frustration for web developers, especially if libraries that abstract away the DOM manipulation are involved (so the web developer can't even change the operation order). I have a really hard time believing that you trigger resource selection when the video is inserted into the document and don't retrigger it afterward, given that... do you? 2. Instead of calling the resource fetch algorithm in step 5/9 There doesn't seem to be such a step... 3. In step 21, instead of waiting forever, just return and let inserting a source element cause it to continue at step 22. Again, the numbering seems to be off. These are steps in the resource selection algorithm, not in the resource fetch algorithm. Yes. Step 5 in the resource selection algorithm I see is: 5. Queue a task to fire a simple event named loadstart at the media element. It has no substeps. Mozilla is implementing this now. How are you interpreting await a stable state when the resource selection algorithm is triggered by the parser? At the moment, given that we don't differentiate betwen pause and spin the event loop internally, it sounds like we plan to treat tis as wait until the next event runs from the event loop. This means we will treat an alert being up as being in a stable state; same for sync XHR, showModalDialog, etc. From the parser we will basically treat it as run asynchronously. Will the result be 100% predictable or depend on random things like how much data the parser already has available from the network? I don't know about result. When the algorithm runs, exactly, will depend on the amount of data the parser parses before returning to the event loop. Does that affect result? -Boris
Re: [whatwg] HTML5 video source dimensions and bitrate
It *appears* that the minimum you're asking for is some way to include
the bitrate/etc. information in the source element so that you can
switch between them in js, right? You're not trying to add something
that will cause changed browser behavior?
In that case, your solution already exists - use the data-*
attributes. source src=foo data-jw-bitrate=2 works just fine. In
existing browsers you can access the attribute with
elem.getAttribute('data-jw-bitrate'), and in future browsers it'll be
elem.data['jw-bitrate'].
~TJ
Re: [whatwg] input type=location proposals
On Tue, Aug 10, 2010 at 2:53 AM, Diogo Resende drese...@thinkdigital.pt wrote: On Sun, 20 Jun 2010, Eitan Adler wrote: For type=gps I was thinking something like the following: 1) type=gps results in a (double?) text box which takes a latitude and a longitude 2a) there is some css option that tells the text box to act like a map instead. 2b) If the css option is on there is also some method of requesting a map source this source could be any existing map provider Then again now that I think about it some more I don't see this working out too well. Does this solve a problem that two type=number controls wouldn't solve? type=url and type=email are here for what? We could all use type=text for everything. Those both offer validation, and in devices that can expose specialty keyboards (such as phones), they can offer a slightly different keyboard for entering data into those (one that makes :, /, and @ easier to type, for example). Thus these are both more powerful than type=text. Does a type=location offer any similar benefits over a pair of type=number inputs? Well we have type=number. I don't know that type=price would be _that_ useful; mostly prices are output, not input. An invoice app would want price input for products or for specific invoice adjustments. Once again, though, what benefit can you gain from type=price over using type=number for this? I don't recall ever seeing an app that allowed you to enter a price in multiple currencies; I've only seen apps that have several price inputs, one for each currency (this can't be replaced by an input type=price, as it means something quite different), and currency converters, which need more information than the browser can provide to be useful in the first place. ~TJ
Re: [whatwg] select element should have a required attribute
On Tue, Aug 10, 2010 at 2:35 AM, Ashley Sheridan a...@ashleysheridan.co.uk wrote: If you receive an empty text box then a required element works to validate against empty input. As you produce the input for the select list, it's pretty stupid to say that it shouldn't have an empty string for a value because you put it there. You're missing the point. We don't put that value there for it to be picked; we put it there *precisely because it shouldn't be picked*, and it's a signal to the user that they need to choose an *actual* option. I can think of lots of places where an empty string is in-fact very useful for a select element, such as filters on search results forms, but if there's any places that I want a value, then I don't leave empty elements lying around. Yes? And when that's valid, you should just *not use @required*, same as when an empty string is a valid value for an input type=text. If you need to do that, then maybe use radio buttons instead. It's okay to replace a radio button with a checkbox when you need that functionality instead, because the two are nearly identical in presentation. It's not generally okay to replace a select with a radio button group, because the two are vastly different presentationally. ~TJ
Re: [whatwg] [html5] r5258 - [e] (0) Some more references to UTF-8.
On Tue, Aug 10, 2010 at 4:53 AM, Leif Halvard Silli xn--mlform-...@xn--mlform-iua.no wrote: wha...@whatwg.org, Mon, 9 Aug 2010 18:16:12 -0700 (PDT): Author: ianh Date: 2010-08-09 18:16:10 -0700 (Mon, 09 Aug 2010) New Revision: 5258 pAuthors are encouraged to use UTF-8. Conformance checkers may - advise authors against using legacy encodings./p + advise authors against using legacy encodings. a href=#refsRFC3629[RFC3629]/a/p Could we replace 'legacy encodings' with a clearer wording - or eventually define what 'legacy encodings' mean? The current wording could give the impression that any encoding other than UTF-8 is a legacy encoding. But it is unclear whether that is actually what is meant. Specifically, it is not clear from the above whether conformance checkers may advice authors against using UTF-16, since UTF-16 generally isn't associated with 'legacy encoding'. That's precisely what's meant. UTF-8 is the encoding of the web. Any and all other encodings are legacy encodings. ~TJ
Re: [whatwg] input type=location proposals
On Tue, 2010-08-10 at 10:00 -0700, Tab Atkins Jr. wrote: On Tue, Aug 10, 2010 at 2:53 AM, Diogo Resende drese...@thinkdigital.pt wrote: On Sun, 20 Jun 2010, Eitan Adler wrote: For type=gps I was thinking something like the following: 1) type=gps results in a (double?) text box which takes a latitude and a longitude 2a) there is some css option that tells the text box to act like a map instead. 2b) If the css option is on there is also some method of requesting a map source this source could be any existing map provider Then again now that I think about it some more I don't see this working out too well. Does this solve a problem that two type=number controls wouldn't solve? type=url and type=email are here for what? We could all use type=text for everything. Those both offer validation, and in devices that can expose specialty keyboards (such as phones), they can offer a slightly different keyboard for entering data into those (one that makes :, /, and @ easier to type, for example). Thus these are both more powerful than type=text. Does a type=location offer any similar benefits over a pair of type=number inputs? Yes, of course. Instead of a numeric keyboard (I never saw one on my iphone), I could just point my current location, or select a location nearby using a map or so. Don't forget about other devices; phones are great but there are bigger screens, like tablets that don't require a special keyboard for input. I think a better validation and a way of context-aware to the browsers would be good. Well we have type=number. I don't know that type=price would be _that_ useful; mostly prices are output, not input. An invoice app would want price input for products or for specific invoice adjustments. Once again, though, what benefit can you gain from type=price over using type=number for this? I don't recall ever seeing an app that allowed you to enter a price in multiple currencies; I've only seen apps that have several price inputs, one for each currency (this can't be replaced by an input type=price, as it means something quite different), and currency converters, which need more information than the browser can provide to be useful in the first place. ~TJ I was just giving an input example. I agree with you on this one, I would be just a matter of localization (currency symbol, number of decimal digits, ..).
Re: [whatwg] Question on iframe.srcdoc address (about:srcdoc)
On Mon, Aug 9, 2010 at 6:39 PM, Justin Schuh jsc...@chromium.org wrote: I'm working on implementing iframe.srcdoc in WebKit, and section 2.5.1 states: This specification defines the URL about:srcdoc as a reserved, though unresolvable, about: URI, that is used as the document's address of iframe srcdoc documents. It seems like it would make more sense for the address to be the data URL of the frame's document. This would be easier to implement in WebKit, and I expect other data URL supporting browsers as well. Is there some reasoning I'm missing for the decision to use about:srcdoc? A few (not necessarily valid) reasons I can think of off the top of my head: 1. data: urls are unique-origin automatically, and there's no special handling of that wrt sandbox=allow-same-origin (that is, the flag does nothing, because the url isn't same-origin to begin with). @srcdoc, on the other hand, should be same-origin by default (though behind a sandbox, and thus *treated* as unique-origin unless the allow-same-origin flag is set). Thus, roundtripping the url back into @src would produce a document with different behavior. 2. @srcdoc doesn't require a doctype for its document, but data: urls need them or else they can trip into quirks mode. Again, roundtripping behavior becomes inconsistent (unless you detect for no-doctype and add it to the data: url automatically). ~TJ
Re: [whatwg] input type=location proposals
On Tue, Aug 10, 2010 at 10:29 AM, Diogo Resende drese...@thinkdigital.pt wrote: On Tue, 2010-08-10 at 10:00 -0700, Tab Atkins Jr. wrote: Does a type=location offer any similar benefits over a pair of type=number inputs? Yes, of course. Instead of a numeric keyboard (I never saw one on my iphone), I could just point my current location, or select a location nearby using a map or so. Don't forget about other devices; phones are great but there are bigger screens, like tablets that don't require a special keyboard for input. I think a better validation and a way of context-aware to the browsers would be good. I do like the idea of being able to automatically input your current location (geolocation without having to touch javascript!). The ability to provide a map seems slightly more limited, but I can see it being useful. Frex, on Android phones it could default to a google maps source, perhaps with the option for a user to swap to a different map provider. (Someone had previously mentioned specifying a map source in CSS, but that seems like the wrong layer for this sort of thing - the user should be the one choosing what map source to use.) ~TJ
Re: [whatwg] Question on iframe.srcdoc address (about:srcdoc)
On Tue, Aug 10, 2010 at 10:30 AM, Tab Atkins Jr. jackalm...@gmail.com wrote: 1. data: urls are unique-origin automatically, and there's no special handling of that wrt sandbox=allow-same-origin (that is, the flag does nothing, because the url isn't same-origin to begin with). �...@srcdoc, on the other hand, should be same-origin by default (though behind a sandbox, and thus *treated* as unique-origin unless the allow-same-origin flag is set). Thus, roundtripping the url back into @src would produce a document with different behavior. Sorry, I was misreading part of the spec. data: urls themselves do indeed have a unique origin, but a Document generated from a data: url has the same origin as the including Document (so iframe src=data:foo/iframe is same-origin). ~TJ
Re: [whatwg] HTML5 video source dimensions and bitrate
On Tue, Aug 10, 2010 at 9:44 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
It *appears* that the minimum you're asking for is some way to include
the bitrate/etc. information in the source element so that you can
switch between them in js, right? You're not trying to add something
that will cause changed browser behavior?
In that case, your solution already exists - use the data-*
attributes. source src=foo data-jw-bitrate=2 works just fine. In
existing browsers you can access the attribute with
elem.getAttribute('data-jw-bitrate'), and in future browsers it'll be
elem.data['jw-bitrate'].
Argh, sorry, memory barfed on me this morning. In future browsers
it'll be elem.dataset.jwBitrate (hyphenated data-* names are
automatically converted to camelcase for easy accessing).
~TJ
Re: [whatwg] input type=location proposals
Eitan Adler: 1) type=gps results in a (double?) text box which takes a latitude and a longitude What about elevation (e.g. floor in a skyscraper, airplane, ISS, submarine)? What about other planets and outer space? Somewhere between 8-| and ;-)
Re: [whatwg] select element should have a required attribute
This seems like the ideal situation to use a placeholder attribute: select required=true placeholder=Select an item... option value=Foo Foo /option option value=Bar Bar /option option value= None /option /select Mike Wilcox http://clubajax.org m...@mikewilcox.net
Re: [whatwg] select element should have a required attribute
On Tue, Aug 10, 2010 at 11:12 AM, Mike Wilcox m...@mikewilcox.net wrote: This seems like the ideal situation to use a placeholder attribute: select required=true placeholder=Select an item... option value=Foo Foo /option option value=Bar Bar /option option value= None /option /select Almost, but not quite. Yes, the value used in this situation is essentially a placeholder value - it performs the same function as input placeholder. However, an input type=text placeholder=foo required will fail validation if the user doesn't interact with it, while a similar select will not at the moment (it will just submit the first value). It could be possible to define the interaction of select, @placeholder, and @required in such a way that it works intelligently, so that the select with a placeholder fails validation if the user doesn't interact with it, but that may be too much magic. I think I'd prefer the simple solution of having it fail @required validation in the same way that text inputs do - when their value is the empty string. ~TJ
Re: [whatwg] HTML resource packages
On Mon, Aug 9, 2010 at 1:40 PM, Justin Lebar justin.le...@gmail.com wrote: Can you provide the content of the page which you used in your whitepaper? (https://bug529208.bugzilla.mozilla.org/attachment.cgi?id=455820) I'll post this to the bug when I get home tonight. But your comments are astute -- the page I used is a pretty bad benchmark for a variety of reasons. It sounds like you probably could hack up a much better one. a) Looks like pages were loaded exactly once, as per your notes? How hard is it to run the tests long enough to get to a 95% confidence interval? Since I was running on a simulated network with no random parameters (e.g. no packet loss), there was very little variance in load time across runs. I suspect you are right. Still, it's good due diligence - especially for a whitepaper :-) The good news is that if it really is consistent, then it should be easy... d) What did you do about subdomains in the test? I assume your test loaded from one subdomain? That's correct. I'm betting time-to-paint goes through the roof with resource bundles:-) It does right now because we don't support incremental extraction, which is why I didn't bother measuring time-to-paint. The hope is that with incremental extraction, we won't take too much of a hit. Well, here is the crux then. What should browsers optimize for? Should we take performance features which optimize for PLT or time-to-first-paint or something else? I have spent a *ton* of time trying to answer this question (as have many others), and this is just a tough one to answer. For now, I believe the Chrome/WebKit teams are in agreement that sacrificing time-to-first render to decrease PLT is a bad idea. I'm not sure what the firefox philosophy here is? One thing we can do to better evaluate features is to simply always measure both metrics. If both metrics get better, then it is a clear win. But without recording both metrics, we just don't really know how to evaluate if a feature is good or bad. Sorry to send you through more work - I am not trying to nix your feature :-( I think it is great you are taking the time to study all of this. Mike -Justin On Mon, Aug 9, 2010 at 1:30 PM, Mike Belshe m...@belshe.com wrote: Justin - Can you provide the content of the page which you used in your whitepaper? (https://bug529208.bugzilla.mozilla.org/attachment.cgi?id=455820) I have a few concerns about the benchmark: a) Looks like pages were loaded exactly once, as per your notes? How hard is it to run the tests long enough to get to a 95% confidence interval? b) As you note in the report, slow start will kill you. I've verified this so many times it makes me sick. If you try more combinations, I believe you'll see this. c) The 1.3MB of subresources in a single bundle seems unrealistic to me. On one hand you say that its similar to CNN, but note that CNN has JS/CSS/images, not just thumbnails like your test. Further, note that CNN pulls these resources from multiple domains; combining them into one domain may work, but certainly makes the test content very different from CNN. So the claim that it is somehow representative seems incorrect. For more accurate data on what websites look like, see http://code.google.com/speed/articles/web-metrics.html d) What did you do about subdomains in the test? I assume your test loaded from one subdomain? e) There is more to a browser than page-load-time. Time-to-first-paint is critical as well. For instance, in WebKit and Chrome, we have specific heuristics which optimize for time-to-render instead of total page load. CNN is always cited as a bad page, but it's really not - it just has a lot of content, both below and above the fold. When the user can interact with the page successfully, the user is happy. In other words, I know I can make webkit's PLT much faster by removing a couple of throttles. But I also know that doing so worsens the user experience by delaying the time to first paint. So - is it possible to measure both times? I'm betting time-to-paint goes through the roof with resource bundles:-) If you provide the content, I'll try to run some tests. It will take a few days. Mike On Mon, Aug 9, 2010 at 9:52 AM, Justin Lebar justin.le...@gmail.com wrote: On Mon, Aug 9, 2010 at 9:47 AM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: If UAs can assume that files with the same path are the same regardless of whether they came from a resource package or which, and they have all but a couple of the files cached, they could request those directly instead of from the resource package, even if a resource package is specified. These kinds of heuristics are far beyond the scope of resource packages as we're planning to implement them. Again, I think this type of behavior is the
Re: [whatwg] select element should have a required attribute
Tab Atkins Jr. jackalm...@gmail.com schrieb am Tue, 10 Aug 2010 11:25:55 -0700: Yes, the value used in this situation is essentially a placeholder value - it performs the same function as input placeholder. However, an input type=text placeholder=foo required will fail validation if the user doesn't interact with it, while a similar select will not at the moment (it will just submit the first value). Keep in mind, that for legacy UAs, that input will *not* fail validation. So the problem is already there. It could be possible to define the interaction of select, @placeholder, and @required in such a way that it works intelligently, so that the select with a placeholder fails validation if the user doesn't interact with it, but that may be too much magic. I think I'd prefer the simple solution of having it fail @required validation in the same way that text inputs do - when their value is the empty string. Overloading the string value to me seems to be more magic, especially in light of the fact that there are legitimate use cases of selecting an empty string — I am currently working on a Wordpress plugin, where a select is used to select (hehe) the locale for an REST API call. Setting the locale to an empty string is not an error, it just returns unlocalized results. Not having @placeholder on select may be a bit simpler to implement, but having it would be more consistent for authors and users alike. Cheers, -- Nils Dagsson Moskopp // erlehmann http://dieweltistgarnichtso.net signature.asc Description: PGP signature
Re: [whatwg] HTML5 video source dimensions and bitrate
On Tue, Aug 10, 2010 at 12:44 PM, Tab Atkins Jr. jackalm...@gmail.com wrote:
It *appears* that the minimum you're asking for is some way to include
the bitrate/etc. information in the source element so that you can
switch between them in js, right? You're not trying to add something
that will cause changed browser behavior?
Correct - we're just trying to do some JS switching.
In that case, your solution already exists - use the data-*
attributes. source src=foo data-jw-bitrate=2 works just fine. In
existing browsers you can access the attribute with
elem.getAttribute('data-jw-bitrate'), and in future browsers it'll be
elem.data['jw-bitrate'].
Wow - I had no idea this was valid. This is exactly what we were
looking for - thanks!
Re: [whatwg] HTML resource packages
On 8/10/10 2:40 PM, Mike Belshe wrote: For now, I believe the Chrome/WebKit teams are in agreement that sacrificing time-to-first render to decrease PLT is a bad idea. I'm not sure what the firefox philosophy here is? Fairly similar (though we have had people complain at us when we do in fact incrementally load a page for 20s that webkit just throws up on the screen all at once after sitting there with a blank viewport for 7s, for what it's worth) -Boris
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Mon, Aug 9, 2010 at 8:41 PM, Ryosuke Niwa ryosuke.n...@gmail.com wrote: All popular calendar systems should be supported. What is the reason we restrict ourselves to Gregorian calendar? HTML5 only concerns itself with how the data is submitted to the server, not how it's presented to the user. For simplicity, there should be exactly one format submitted to the server, so that the server doesn't have to implement every major calendar system on the off chance it has some user whose browser is configured to submit dates in the Thai solar calendar or something. The browser is free to implement whatever UI it likes, though -- the Japanese version of a browser might accept Japanese eras for years, the Hebrew version might accept the Jewish calendar, whatever. You can ask browsers to implement that support right now; HTML5 doesn't have anything to say either way. The browser just has to convert to a valid Gregorian date before submitting to the server. That allows any calendar that can be converted programmatically to the Gregorian calendar.
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Tue, Aug 10, 2010 at 1:38 PM, Aryeh Gregor simetrical+...@gmail.comsimetrical%2b...@gmail.com wrote: For simplicity, there should be exactly one format submitted to the server, so that the server doesn't have to implement every major calendar system on the off chance it has some user whose browser is configured to submit dates in the Thai solar calendar or something. The browser is free to implement whatever UI it likes, though -- the Japanese version of a browser might accept Japanese eras for years, the Hebrew version might accept the Jewish calendar, whatever. Right, that's what I meant. But to implement that, we need to know that certain text field is accepting year, not a 4-digit number. Each UA can then implement a year picker suitable for its users. Best, Ryosuke
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
2010/8/9 Ian Fette (イアンフェッティ) ife...@google.com I don't understand why I would need an input type=year to get this right though. If the bank wants something in 年号 it can just let the user type in 1985 and convert that via JS to 昭和60年, no? If anything, having some sort of picker seems like it would be more complicated. The problem is that it can't do the inserve of that. What if the user wanted to type in 昭和60年 but server only accepts 1985? We want some UI for accepting 昭和60年 and automatically convert it to 1985 to submit. But to implement that, UA needs to know that certain text field is accepting year, not some random digits. I really don't know if it's worth spending time on something that is such a minor use case, and can frankly be handled fine without a dedicated input type. And niwa-san, on every document I've ever filled out for the Japanese government, I've always written 1985年 instead of 昭和60年 and it's yet to cause me any problems ;-) I do understand that there are some sites that want it written in the traditional form, but these seem to be precious few and far between, and frankly are not the sites I would expect to find HTML5 form input elements on anyways if the US government is any indication of moving to new standards... But there are users who don't know how to convert from 昭和xx年 to year 19xx (like my parents and grandparents who has to spend at least half a minute recalling their birth years in Gregorian calendar), and only remember their birth years in 昭和xx. Some people even buy a conversion table and keep it in their wallet just so that they can convert between two systems. Forcing them to remember their birth years in 19xx isn't user-friendly and simply a poor UI localization. Best, Ryosuke
Re: [whatwg] Please consider adding a couple more datetime input types - type=year and type=month-day
On Tue, Aug 10, 2010 at 1:53 PM, Ryosuke Niwa ryosuke.n...@gmail.com wrote: On Tue, Aug 10, 2010 at 1:38 PM, Aryeh Gregor simetrical+...@gmail.com wrote: For simplicity, there should be exactly one format submitted to the server, so that the server doesn't have to implement every major calendar system on the off chance it has some user whose browser is configured to submit dates in the Thai solar calendar or something. The browser is free to implement whatever UI it likes, though -- the Japanese version of a browser might accept Japanese eras for years, the Hebrew version might accept the Jewish calendar, whatever. Right, that's what I meant. But to implement that, we need to know that certain text field is accepting year, not a 4-digit number. Each UA can then implement a year picker suitable for its users. Best, Ryosuke That's probably the most convincing point for adding a year type I've heard so far. I'd agree with a year type just based on that. -- ~Jonathan
Re: [whatwg] Should window.name be [Replaceable]?
On Sun, 4 Jul 2010, Joseph Pecoraro wrote: Should window.name be [Replaceable]? If there are pages that depend on it being replaceable, or if browsers have reliably implemented it that way, then yes. https://bug-19967-attachments.webkit.org/attachment.cgi?id=60491 Browser Results: - Safari 5 / WebKit Nightly and Chrome 5 NOT [Replaceable], printing string,string,string - Firefox 3.6.3 / 3.7a5 and Opera 10.5.3 / 10.6 [Replaceable], printing string,string,number - I didn't have access to IE to test. I'd appreciate someone giving it a shot to see how they act. I am told IE says string,string,string (thanks to Tab and Aryeh). This argues that we should not make it replaceable unless it breaks pages. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Iframe dimensions
On Mon, 5 Jul 2010, Markus Ernst wrote: I found that the dimensions of the iframe element are handled along with those of other embedded content such as img, video and others: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-map-element.html#attr-dim-width There is no indication about what a UA should do when dimension attributes are not specified. That's handled by CSS. UAs do seem to handle this case differently for those elements: To an img element, they apply the actual pixel dimensions of the image file, while they seem to apply default dimensions to iframe elements. Right, because iframes have no intrinsic dimensions (except with seamless). First, this sounds somehow complicated to me Yeah, the handling of intrinsic sizes in CSS is non-trivial. and second, I don't understand why the dimensions of non-seamless iframes should not get the benefits of author-friendly (and user-friendly) dimension handling. It would let you examine pages cross-origin, leaking information such as whether the user is logged in. I want to suggest to provide a way to make an iframe behave just like any block element regarding width and height, that means: If no dimensions are specified, use the full available width, and apply the height needed to display the full content. That's what happens for seamless iframes. We can't do it for cross-origin iframes (security) or for undecorated iframes (compatibility). Example: http://test.rapid.ch/de/haendler-schweiz/iseki.html (This is under construction.) As a workaround to the height problem, I applied a script that adjusts the iframe height to the available height in the browser window. But of course the user experience would be more consistent if the page could behave like a single page, with only one scrollbar at the right of the browser window. If you control both pages and can't use seamless, you can use postMessage() to negotiate a size. On the long term, I expect we'll make seamless work with CORS somehow. I'm waiting until we properly understand how CORS is used in the wild before adding it all over the place in HTML. On Tue, 6 Jul 2010, Markus Ernst wrote: My problem is this sentence in the spec for seamless: This will cause links to open in the parent browsing context. In an application like http://test.rapid.ch/de/haendler-schweiz/iseki.html, the external page should be able to re-call itself inside the iframe, for example if a sort link is clicked or a search form submitted. On Tue, 6 Jul 2010, Ashley Sheridan wrote: Could you explicitly call the _self target in links in the frame? I wasn't sure if the target attribute was going or not, but I'd expect target=_self to override the default seamless action. Good point. Fixed. You can now work around this by targetting the frame explicitly using base target=_self. (Or by using target=foo if the iframe has name=foo.) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Clarification request for charset/characterSet/defaultCharset
On Tue, 6 Jul 2010, Nicholas Zakas wrote: I was just reading through the spec and am having trouble understanding the details of document.charset, document.characterSet, and document.defaultCharset. It seems to me that document.characterSet is simply a read-only equivalent of document.charset (I'm guessing these are both here due to already-existing implementations), which is a little confusing but not terribly so. I'm more interested in document.defaultCharset and how it relates to the others. All three are there for historical reasons. Some questions: 1) Should document.charset/document.characterSet always start out equivalent to document.defaultCharset? What do you mean by start out? 2) What is the canonical source of truth for document.defaultCharset (is this a system setting, a browser setting, or a document setting)? There is no truth to speak of for defaultCharset. The browser can return any arbitrary value. 3) If document.charset is set to a new value, is there any change reflected in document.defaultCharset? What about vice-versa? Nope. defaultCharset is read-only, so cannot be set by the author. Its return value can vary arbitrarily. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 (including next generation additions still in development) - Mozilla Firefox (Not Responding)
On Wed, 7 Jul 2010, Garrett Smith wrote: This is about the fourth time I've said it here. Can the person in charge of writing the slow and buggy ajvascript on the HTML 5 spec please remove that? The problem is that that whatwg page causes freezes and crashes [...] That sounds like a bug in the browser. No page should cause such problems. I don't see such problems with the browsers I use to view the spec. On Wed, 7 Jul 2010, Boris Zbarsky wrote: I'll just note that part of the reason it's a stress test, apart from the old Firefox issue, is that it tries to be clever and not hang the browser which actually causes the browser to do a lot more work. On my machine here, if the spec's script were not trying for the clever thing, it would take about 1-2 seconds (with a completely hung browser during that time) to do what it currently takes anywhere from 8 to 25 seconds to do, during which time the browser is largely unresponsive anyway. I've tried to tweak the scripts to not be quite as silly in the way they split up the work (in particular, now they won't split up the work if it's being done fast -- in browsers I tested, this reduced the problem just to the restyling being slow, in some cases taking a few seconds). For the record, the spec isn't seriously intended to be a stress test; that is stresses browsers is merely a side-effect of it being a big document with lots of complicated scripts and styles. There are (slightly less useful) multipage versions of the specs available for people who prefer those; they are referenced at the top of the spec, and most links to the specs on the whatwg.org site point to those multipage versions. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Adding descent to TextMetrics
On Thu, 8 Jul 2010, Charles Pritchard wrote: We've been doing some work with html line boxes; mainly, mixed font styles in a text area, using the HTML Canvas element. While Canvas fillText does have the textBaseline attribute, in order to set the current alignment, it does not provide enough metrics through the measureText function for us to exploit the textBaseline attribute across fonts (sizes and styles). Adding descent, to the measureText object would allow us to do more. Currently, TextMetrics only returns width. I'm proposing adding descent to that list. I recommend not using canvas for text editing. Adding more features to TextMetrics is on the cards for a future version of the canvas API, but at the moment I'm waiting until more of the spec is reliably implemented before adding more features, so that we don't get too far ahead of the spec. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Default value of complete attribute on new Image objects
On Thu, 8 Jul 2010, Andreas Kling wrote:
The current HTML5 specification says:
The IDL attribute complete must return true if the user agent has
fetched the image specified in the src attribute, and it is in a
supported image type (i.e. it was decoded without fatal errors), even if
the final task queued by the networking task source for the fetching of
the image resource has not yet been processed. Otherwise, the attribute
must return false. [1]
This reads to me as if a new Image() should have complete=false
No browser currently does this AFAIK.
On Fri, 9 Jul 2010, Diego Perini wrote:
Just to add that also by using DOM methods like:
document.createElement('img').complete; // true
the result is the same: complete is always true. Only tested on Firefox
3.5.10 and Opera 10.60.
I've updated the spec to have complete return true if the src is the empty
string.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: @srctype or @type on iframe
On Tue, 13 Jul 2010, Gordon P. Hemsley wrote: There a number of attributes that are designed to give the user agent a preview of what MIME type to except for referenced resource. (And there are also attributes like @hreflang that preview other things.) And yet, iframe, which has to load a full document, has no ability to allow the user agent to determine compatibility. Thus, I propose doing one of the following: (1) add @srctype to iframe (2) extend the meaning of @type that applies to a, area, and link to apply to iframe, as well I'm more inclined to believe that option (2) is the better option. What problem would this solve? User agents fetch anything specified in an iframe; are you proposing we change that? It should not be assumed that whatever resource included via iframe is going to be of type 'text/html' or another easily parsable type. Thus, it could be helpful for the author to give the user agent a hint as to what type of document it is requesting be displayed inline, and allow the user agent to choose not to display the contents of the iframe if it feels it cannot support it. The particular use case that prompted me to think about this is including a PDF via iframe. In Firefox (last I checked), one is required to install a separate add-on in order to support in-browser display of PDF files on Mac OS X, since there is no native or integrated Adobe Reader support available. Without the add-on, the user will be prompted to download the PDF file, which can be very disconcerting if the user wasn't even expecting a PDF file. And I'm sure there are plenty of other instances where this same situation occurs. (TIFF files, perhaps? Like on the U.S. Patent Office's website?) Now, I'm not a spec implementor by any means, but I am a web author and a web user, so I've been on both sides of this issue. And it doesn't appear that it would be too complicated to extend the existing support of @type. Surely a better solution is to make files that would be downloaded simply display an inline prompt (rather than a pop-up prompt) in this case. On Tue, 13 Jul 2010, Gordon P. Hemsley wrote: Well, the idea is to have the browser operate more intelligently than that. The page in the iframe is (by definition) not the primary document that the user is trying to load, so it shouldn't have the power steal the user's attention immediately upon page load. It would be very disorienting, and would likely cause the user to lose their train of thought. I was thinking more along the lines of Flashblock does or what happens when the window in an iframe can't load: The content would be replaced somehow by a message and a button/link to allow the user to manually download the contents of the iframe, if they so choose. It shouldn't make that decision for the user, as it's not the user's fault that their browser does not support the format of some ancillary document. It seems that if browsers wanted to do that, they could do it today using the information from the Content-Type header. The type= attribute would only allow them to do it slightly quicker, and slightly less accurately. On Tue, 13 Jul 2010, Marques Johansson wrote: In one of the video related threads someone from Opera said that browsers have a rough time trying to figure out how to intelligently handle video content fetches. I think that a type suggestion, before the Content-type could help a browser use a more optimal fetch behavior. For video, where it makes sense, we already have it. In any case, I recommend following this suggestion from the FAQ for new features such as this: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F Cheers, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Fwd: Discussing WebSRT and alternatives/improvements
On Tue, Aug 10, 2010 at 7:49 PM, Philip Jägenstedt phil...@opera.comwrote: On Tue, 10 Aug 2010 01:34:02 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: On Tue, Aug 10, 2010 at 12:04 AM, Philip Jägenstedt phil...@opera.com wrote: On Sat, 07 Aug 2010 09:57:39 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: I guess this is in support of Henri's proposal of parsing the cue using the HTML fragment parser (same as innerHTML)? That would be easy to implement, but how do we then mark up speakers? Using span class=narrator/span around each cue is very verbose. HTML isn't very good for marking up dialog, which is quite a limitation when dealing with subtitles... I actually think that the span @class mechanism is much more flexible than what we have in WebSRT right now. If we want multiple speakers to be able to speak in the same subtitle, then that's not possible in WebSRT. It's a little more verbose in HTML, but not massively. We might be able to add a special markup similar to the [timestamp] markup that Hixie introduced for Karaoke. This is beyond the innerHTML parser and I am not sure if it breaks it. But if it doesn't, then maybe we can also introduce a [voice] marker to be used similarly? An HTML parser parsing 1 or 00:01:30 will produce text nodes 1 and 00:01:30. Without having read the HTML parsing algorithm I guess that elements need to begin with a letter or similar. So, it's not possible to (ab)use the HTML parser to handle inner timestamps of numerical voices, we'd have to replace those with something else, probably more verbose. I have checked the parse spec and http://www.whatwg.org/specs/web-apps/current-work/#tag-open-state indeed implies that a tag starting with a number is a parse error. Both, the timestamps and the voice markers thus seem problems when going with an innerHTML parser. Is there a way to resolve this? I mean: I'd quite happily drop the voice markers for a span @class but I am not sure what to do about the timestamps. We could do what I did in WMML and introduce a t element with the timestamp as a @at attribute, but that is again more verbose. We could also introduce an @at attribute in span which would then at least end up in the DOM and can be dealt with specially. Just for those who think it's a fancy karaoke feature and isn't really required: it's actually also a useful feature for captions, in particular when recording live captions that are usually paint-on. Requirement CC-14 on http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements also refers to this need and 608/708 captions provide this functionality, too. Similarly, I think that the WebSRT parser should be designed to ignore things that it doesn't recognize, in particular unknown voices (if we keep those). Requiring parsers to fail when the version number is increased oh, you misunderstood me: I am not saying that parser have to fail - it's good if they don't. But I am saying that if we make a change to the specification that is not backwards compatible with the previous one and will thus invariably break parsers, we have to notify parsers somehow such that if they get parse errors they can e.g. notify the user that this is a new version of the WebSRT format which their software doesn't support yet. A browser won't bother their users by saying hey, there was something in this page I didn't understand, as users won't know what to do to fix it. I'm not overly worried about browsers. They will just display the wrong text. They are not normally an authoring or transcoding application. I am more worried about non-browser applications here, in particular those where interpreting the text the wrong way will lead to disaster, such as the wrong data in an archive etc. Think for example about the case where we had a requirement that a double newline starts a new cue, but now we want to introduce a means where the double newline is escaped and can be made part of a cue. Other formats keep track of their version, such as MS Word files. It is to be hoped that most new features can be introduced without breaking backwards compatibility and we can write the parsing requirements such that certain things will be ignored, but in and of itself, WebSRT doesn't provide for this extensibility. Right now, there is for example extensibility with the WebSRT settings parsing (that's the stuff behind the timestamps) where further setting:value settings can be introduced. But for example the introduction of new cue identifiers (that's the marker at the start of a cue) would be difficult without a version string, since anything that doesn't match the given list will just be parsed as cue-internal tag and thus end up as part of the cue text where plain text parsing is used. The bug I filed suggested allowing arbitrary voices, to simplify the parser and to make future extensions possible. For a web format I think this is a
Re: [whatwg] Communicating between different-origin frames
On Wed, 14 Jul 2010, James Graham wrote: Following some discussion of [1], it was pointed out to me that it is possible to make two pages on separate subdomains communicate without either setting their document.domain by proxing the communication through pages that have set their document.domain. There is a demo of this at [2]. I'm not sure if this is already well-known nor whether it is harmless or not. [1] http://my.opera.com/hallvors/blog/2010/07/13/ebay-versus-security-policy-consistency [2] http://sloth.whyi.org/~jl/cross-domain.html On Wed, 14 Jul 2010, Adam Barth wrote: This is well-known http://www.collinjackson.com/research/papers/fp801-jackson.pdf but not a good idea (see Section 4.4): http://www.adambarth.com/papers/2009/barth-weinberger-song.pdf I haven't changed the spec regarding this, since it's not clear what a better solution would be. If anyone has a concrete proposal for what we should require, please let me know. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Default value of complete attribute on new Image objects
On Wed, Aug 11, 2010 at 12:23 AM, Ian Hickson i...@hixie.ch wrote: I've updated the spec to have complete return true if the src is the empty string. Some canvas methods (drawImage, createPattern) are defined in terms of the complete attribute (If the image argument is an HTMLImageElement object whose complete attribute is false, [...] then the implementation must return without drawing anything.). Now that it can be true when the image doesn't have any image data, what should they do when passed such an image? -- Philip Taylor exc...@gmail.com
Re: [whatwg] Default value of complete attribute on new Image objects
On Tue, Aug 10, 2010 at 4:56 PM, Philip Taylor excors+wha...@gmail.com wrote: On Wed, Aug 11, 2010 at 12:23 AM, Ian Hickson i...@hixie.ch wrote: I've updated the spec to have complete return true if the src is the empty string. Some canvas methods (drawImage, createPattern) are defined in terms of the complete attribute (If the image argument is an HTMLImageElement object whose complete attribute is false, [...] then the implementation must return without drawing anything.). Now that it can be true when the image doesn't have any image data, what should they do when passed such an image? Isn't the image fully loaded, just empty? Seems like drawing such an image should act normal. It just so happens that normal for an empty image would be to draw nothing? Just have to avoid divide-by-zero errors when creating patterns :) / Jonas
Re: [whatwg] Canvas coordinate space units
On Wed, 14 Jul 2010, David Flanagan wrote: I'm confused by the term coordinate space units as applied to the canvas spec. It does not seem to be defined. It seems self-explanatory... it refers to the units used by the coordinate space. What is ambiguous? The coordinate space is defined earlier; its size is defined near the top of the canvas section, and its direction is defined near the top of the '2d' section. It is used in the definition of the translate() method, for example, and seems to imply that coordinate space units are affected by scale() operations. Nothing is implied in the spec; if something isn't said explicitly, then it isn't said and doesn't apply. All that translate() does is change the transformation matrix. Are coordinate space units affected by scaling or not? No. Are lineWidths supposed to be scaled? Yes (the stroke must itself also be subjected to the current transformation matrix). Are shadow offset supposed to be scaled? No. I think a clearer definition of coordinate spaces would be helpful. Maybe device space for the underlying pixmap, canvas space for the coordinates defined by the width and height attributes of the canvas, and user space for the space defined by the current transformation matrix? They are device pixels, coordinate space, and coordinates to which the current transformation matrix is applied respectively. On Wed, 14 Jul 2010, David Flanagan wrote: As an aside, do you think any implementations actually do that? It seems to me that it would cause real problems with drawImage(): images would look bad compared to drawn graphics... Only if they were low-resolution images. On Thu, 15 Jul 2010, Philip Taylor wrote: (I don't think it's clear exactly *how* the stroke will be scaled, or rotated or translated or skewed etc - I'd like it more if everything was specified in precise geometric algorithms, rather than fluffy prose, but it seems like implementations interoperate anyway and test cases can tell when they get it wrong so there's probably not much practical benefit in rewriting everything much more precisely.) Yeah. Agreed on both counts. On Thu, 15 Jul 2010, Aryeh Gregor wrote: Ideally, we shouldn't be relying on test-cases here. If it can be specified more precisely, it should be, if someone is willing and able to write the text. It's already been pointed out that some browsers aren't interoperable on some points. I generally try to tighten it up when they don't. It would probably be a lot of work to rewrite this whole section; I'm reluctant to do that if there's not a compelling reason to (theoretical purity isn't compelling!). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML5 video source dimensions and bitrate
On Wed, Aug 11, 2010 at 2:35 AM, Zachary Ozer z...@longtailvideo.comwrote: On Mon, Aug 9, 2010 at 8:05 PM, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: Have you looked at the @media attribute? I would suggest to put them there. As that's not currently specified in media queries, you might want to demonstrate how it could work and make a proposal to extend the media queries. I thought about suggesting something like bitrate a bandwidth to media queries. The syntax would look something like: video width=720 source src=video-480.mp4 media=(width:480px) and (min-bitrate:2mbps) source src=video-720.mp4 media=(width:720px) and (min-bitrate:4mbps) source src=video-1080.mp4 media=(width:1080px) and (min-bitrate:20mbps) /video The problem is that the user agent would have to then know what bitrate can be supported between you and that source. User agents don't currently keep track of this information (so far as I'm aware), and even if they did, it's highly variable based on your location, the website you're visiting, etc. Additionally, while media queries do help content producers specify which resource would be selected for a device under ideal circumstances, it doesn't really allow for degradation. However, if you look at what's out there today, it's pretty common to allow users to switch to a degraded experience as needed. I can think of a few solutions that might make sense here: * Allow source sub-elements / groupings and provide a call to switch between elements of a group. Ideally, this would look something like: video width=720px sourcegroup type=video/mp4 media=screen and (device-aspect-ratio: 16/9) source src=video-1080.mp4 meta=width:1920px;height:1080px;bitrate:20mbps; source src=video-720.mp4 meta=width:1280px;height:720px;bitrate:4mbps; /sourcegroup sourcegroup type=video/mp4 media=screen and (device-aspect-ratio: 4/3) source src=video-480.mp4 meta=width:640px;height:480px;bitrate:2mbps; /sourcegroup sourcegroup type=video/ogv source src=video-480.ogv meta=width:640px;height:480px;bitrate:2mbps; source src=video-720.ogv meta=width:1280px;height:720px;bitrate:4mbps; source src=video-1080.ogv meta=width:1920px;height:1080px;bitrate:20mbps; /sourcegroup /video * Have user agents keep track of information about dropped frames. Publishers could then list multiple valid sources in order of rank. When the dropped frame rate increased, either the user agent or a bit of JavaScript could remove that source and re-run the resource selection algorithm. It's good to have thought this through. I agree, this isn't a workable solution, since the whole bandwidth switching logic is introduced into the browsers, when in fact it should happen in the media framework with information from the network stack without a need for the Web page to even be aware of this. After all, it's really different versions of the same resource that we are dealing with. That's also what happens in adaptive HTTP streaming solutions of Apple, MS, Adobe and MPEG-4. So, to generalise this, I agree there should be a solution such as what Chris Double is suggesting with an additional resource describing what files can be switched between and then JavaScript doing the switching. This could eventually also be introduced into HTML5, if it's done with the same additional resource format for all video formats. In this case, would you still require an additional attribute? Cheers, Silvia.
[whatwg] Please consider time syntax processing improvements for better DRY and thus more accurate data over time
We know from experience with past methods of duplicated invisible (meta)data, and more recently, development/use/experience with visible microformats, that when we are able to re-use the visible data, published *once*, by humans for humans, we get more accurate data over time, than when we have at times asked for *duplicating* the data in a different (more machine readable) format (or location). This experience yielded the microformats adoption of the DRY principle - don't repeat yourself - in application to (meta)dataformat designs and techniques. The time element currently encourages DRY violations in most of its use cases (duplication of datetime information inside the 'datetime' attribute in addition to the visible content of the element). This is not a new problem, we've had much the same DRY problem in microformats representations of dates and times, originally with (excessive and in many cases inaccessible) use of the abbr element. Subsequently (through years of debate, experimentation, iteration) we've largely addressed both most of the DRY violations (or greatly mitigated their impact) and resolved accessibility related abbr problems with the introduction and successful adoption of the Value Class Pattern (developed in parallel with the time element, and not surprisingly with some newer improvements). http://microformats.org/wiki/value-class-pattern#Date_and_time_values We'd like to see the lessons learned (and improvements made as a result of the value class pattern) adopted in HTML5 as well, for much the same reasons, to make the HTML5 time element the best and most long term accurate way to represent all date and time information in microformats (or microdata for that matter). Accordingly, please consider the following time syntax processing improvements for better DRY (and mitigation) and thus more accurate data over time. 1. composite nested time elements. In short, instead of this (actual example derived from markup of blog post HTML5 watch[1] by Jeremy Keith) time class=published datetime=2009-12-13T17:43:29 Sunday, December 13th, 2009 5:43pm /time We want to be able to do this: time class=published time datetime=2009-12-13Sunday, December 13th, 2009/time time datetime=17:43:295:43pm/time /time and have the parent time element composite a complete datetime from the child time elements with separate date and time. The datetime values are more readable (per accessibility research etc.), and thus more easily human verifiable as being the same value as the in-content text, thus resulting in incrementally more accurate data over time. This type of date and time compositing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5. More details, examples, use-cases here: http://wiki.whatwg.org/wiki/Time_element#composite_nested_time_elements I encourage web developers and browser implementers to add their opinions and comments to that wiki page section. 2. am pm and coarser time parsing Summary: by permitting am pm and coarser time values, many more instances of time markup can be minimized to in-content only (not requiring a datetime attribute) and thus reduce many DRY violations. In short, instead of this (actual example derived from markup of blog post HTML5 watch by Jeremy Keith, with nested time elements per previous proposal) time class=published time datetime=2009-12-13Sunday, December 13th, 2009/time time datetime=17:43:295:43pm/time /time We want to be able to do this: time class=published time datetime=2009-12-13Sunday, December 13th, 2009/time time5:43pm/time /time It's a minor DRY improvement (time info is no longer duplicated), but one that we think is worth it across the numerous pieces of content authored as such and the resulting increased accuracy from DRY reduction. This type of am pm parsing as spec'd in the Value Class Pattern has been interoperably implemented and shipped (Operator, X2V). Thus we think it is reasonable to add this similar feature to HTML5. More details, examples, use-cases here: http://wiki.whatwg.org/wiki/Time_element#am_pm_and_coarser_time_parsing I encourage web developers and browser implementers to add their opinions and comments to that wiki page section. Thanks for your consideration, Tantek [1] http://adactio.com/journal/1632/ -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Re: [whatwg] Default value of complete attribute on new Image objects
On Wed, Aug 11, 2010 at 1:06 AM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 10, 2010 at 4:56 PM, Philip Taylor excors+wha...@gmail.com wrote: On Wed, Aug 11, 2010 at 12:23 AM, Ian Hickson i...@hixie.ch wrote: I've updated the spec to have complete return true if the src is the empty string. Some canvas methods (drawImage, createPattern) are defined in terms of the complete attribute (If the image argument is an HTMLImageElement object whose complete attribute is false, [...] then the implementation must return without drawing anything.). Now that it can be true when the image doesn't have any image data, what should they do when passed such an image? Isn't the image fully loaded, just empty? Depends how you define the concept of fully loaded, I guess. The spec says an empty src is invalid and triggers an error event and makes the image not available (but now also complete), so it's not entirely the same as a normal non-empty image. Seems like drawing such an image should act normal. It just so happens that normal for an empty image would be to draw nothing? Just have to avoid divide-by-zero errors when creating patterns :) Probably should do the same as a 0-pixel canvas (If the image argument is an HTMLCanvasElement object with either a horizontal dimension or a vertical dimension equal to zero, then the implementation must raise an INVALID_STATE_ERR exception.). (The spec currently assumes complete HTMLImageElements always have non-zero size, so the dimension check isn't applied to them.) -- Philip Taylor exc...@gmail.com
Re: [whatwg] Non-blocking SVG Canvas?
I think I would really like to get some input from people who have done some work on the SVG spec. :) www-...@w3.org is the right place for that. Thanks, I sent off a question there. However, back to HTML5 4.8.16 It says that the svg element is in the SVG namespace... however, it describes the element as being: embedded content, phrasing content, and flow content categories for the purposes of the content models in this specification. Would describing svg under these 3 content models in any way imply that the svg tag should act like an invisible box to capture events (and block everything underneath). Essentially, if I were to find out that according to the SVG specs, the svg canvas should not block items underneath... then my question is does anything in the HTML5 spec say that it should block? ... or perhaps it could be interpreted either way?
Re: [whatwg] postMessage's target origin argument can be a full URL in some implementations
Based on the feedback sent to this list a few weeks ago, I've changed postMessage() back to what it was originally. Unfortunately this means the feedback that was sent after the initial implementation experience will not be taken into account. I made this change because implementations are now unable to change due to existing sites using these features. Specifically, this means the magic / string is no longer supported, and paths are ignored rather than throwing an exception. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] push/replaceState interacting with POSTs
On Fri, 16 Jul 2010, Justin Lebar wrote: We have a minor issue using replaceState in Bugzilla that we may or may not want to fix up in the spec. When you make a change to a bug, Bugzilla POSTs you from a nice-looking URL, say https://bugzilla.mozilla.org/show_bug.cgi?id=577720 , to https://bugzilla.mozilla.org/process_bug.cgi This is annoying because it breaks refresh and bookmarking, even though process_bug.cgi is logically displaying the same page that show_bug.cgi was previously displaying. Apparently fixing this the Right Way is difficult in Bugzilla, so the developers are considering using history.replaceState() to change the URL of process_bug.cgi back to show_bug.cgi?id=xxx. This works well, but it has the small problem that when you refresh the page after processing a bug, Firefox shows you the warning it shows when you refresh a page which was POST'ed to. I wonder if calling push/replaceState should cause the browser to consider the affected history entry as the result of a GET, even if it was the result of a POST. Bugzilla may be abusing the API here a bit, but it's still not clear that we're doing the right thing when we prompt the user on a refresh (or if we were to refuse to load the page on a session restore since the load isn't idempotent). This seems reasonable. I recommend implementing it and reporting on whether it is considered a success. If it is, I'd be happy to change the spec to require this. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] postMessage's target origin argument can be a full URL in some implementations
On 8/10/10 9:11 PM, Ian Hickson wrote: Specifically, this means the magic / string is no longer supported Why? That seemed like a useful feature, and not something likely to break anyone out there In particular, it allows use cases that are not possible right now (e.g. reasonable postMessage from an about:blank page to a page that has the same origin as the about:blank page). -Boris
Re: [whatwg] postMessage's target origin argument can be a full URL in some implementations
On Tue, Aug 10, 2010 at 9:28 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 8/10/10 9:11 PM, Ian Hickson wrote: Specifically, this means the magic / string is no longer supported Why? That seemed like a useful feature, and not something likely to break anyone out there In particular, it allows use cases that are not possible right now (e.g. reasonable postMessage from an about:blank page to a page that has the same origin as the about:blank page). Yeah, it seems like there's a big difference between breaking changes (e.g., rejecting previously valid inputs) and non-breaking changes (e.g., allowing some new, previously invalid inputs). Adam
