Re: [whatwg] [URL] Starting work on a URL spec
On 7/24/2010 2:02 PM, Boris Zbarsky wrote: On 7/24/10 1:50 AM, Brett Zamir wrote: I would be particularly interested in data on this last, across different browsers, operating systems, and locales... There seem to be servers out there expecting their URIs in UTF-8 and others expecting them in ISO-8859-1, and it's not clear to me how to make things work with them all. Seems to me that if they are not in UTF-8, they should be treated as bugs, even if that is not a de jure standard. Treated as bugs by whom? By the servers/scripting languages. While it is great that the browsers are involved in the process, I think it would be reasonable to invite the other stake-holders to join the discussions. The scenario is that a user types some non-ASCII text in the url bar. This needs to be url-encoded to actually go on the wire, which raises the question of what encoding. If the user is using IRIs, the answer is UTF-8. A number of servers barf if you do this, especially because some server-side scripting languages (PHP, e.g., last I checked) default to URI-unescaping via something other than UTF-8. Hopefully to be fixed in PHP6 with its promise of full Unicode support... Though per http://www.slideshare.net/kfish/unicode-php6-presentation : *Slide 34: *Conversions & Encoding “HTTP Input Encoding” With Unicode semantics switch enabled, we need to convert HTTP input to Unicode GET requests have no encoding at all and POST ones rarely come marked with the encoding Encoding detection is not reliable *Correctly decoding HTTP input is somewhat of an unsolved problem* *Slide 35: *Conversions & Encoding “HTTP Input Encoding” PHP will perform lazy decoding Delays decoding data in $_GET, $_POST, and $_REQUEST until the first time you access them Allows user to set expected encoding or just rely on a default one Allows decoding errors to be handled by the same mechanism Applications should also use filter extension to filter incoming data So some browser encode the non-query part of the URI as UTF-8 and the query part as ... something (user's default filesystem encoding, say, for lack of a better guess). Others always use UTF-8 (and end up with some servers not usable). Others... I have no idea. That's why I want data. ;) In particular, while the "just use UTF-8, and if the user can't access the site sucks to be the user" approach has a certain theoretical-purity appeal, it doesn't seem like something I want to do to my friends and family (always a good criterion for things you'd like to do to users). What I meant is to try to get the server systems on board to fix the issue, including in the long-term. I appreciate you all being admirably practical champions of present-day compatibility, though I'd hope there is a vision to make things work better for the future, even if there will be some inevitable growing pains for a subset of users (as the lack of standardization no doubt creates pains for another subset as it is). Brett
Re: [whatwg] Constraint validation for maxlength
On Sat, 24 Jul 2010 00:21:10 +0200, Aryeh Gregor wrote: On Thu, Jul 22, 2010 at 5:46 PM, Jonas Sicking wrote: I think that depends largely on how many, and how big, sites are affected by this. Do you have a list of known sites with this issue? No, I was just raising the issue to see what people thought. Maybe someone from Opera could share a reason why they don't follow the spec here, unless the spec was different when they implemented it or something. From what I can see this was changed in Opera four years ago after some debate [1]. The big problem was pre- and script-filled fields that exceeded maxlength. Users got confused when fields they hadn't touched threw an error. See also [2] and [3] Sites that broke back then were: (I don't know know if any of them still are affected, many require login) The YaBB forum software SuperOffice eJournal (a support system Opera used) http://kayak.com/ (was fixed after we pointed it out) http://www.costco.com/ (internal navigation) http://www.nowwhere.com.au (zooming maps) http://www.zap2it.com http://www.kwick.de/forum 1) https://bugs.opera.com/browse/DSK-151609 (sorry, Opera access only) 2) http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-February/005695.html 3) http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2006-January/005459.html -- Ola P. Kleiven Core Compatibility PM Opera Software
Re: [whatwg] [URL] Starting work on a URL spec
On 7/24/10 1:50 AM, Brett Zamir wrote: I would be particularly interested in data on this last, across different browsers, operating systems, and locales... There seem to be servers out there expecting their URIs in UTF-8 and others expecting them in ISO-8859-1, and it's not clear to me how to make things work with them all. Seems to me that if they are not in UTF-8, they should be treated as bugs, even if that is not a de jure standard. Treated as bugs by whom? The scenario is that a user types some non-ASCII text in the url bar. This needs to be url-encoded to actually go on the wire, which raises the question of what encoding. If the user is using IRIs, the answer is UTF-8. A number of servers barf if you do this, especially because some server-side scripting languages (PHP, e.g., last I checked) default to URI-unescaping via something other than UTF-8. So some browser encode the non-query part of the URI as UTF-8 and the query part as ... something (user's default filesystem encoding, say, for lack of a better guess). Others always use UTF-8 (and end up with some servers not usable). Others... I have no idea. That's why I want data. ;) In particular, while the "just use UTF-8, and if the user can't access the site sucks to be the user" approach has a certain theoretical-purity appeal, it doesn't seem like something I want to do to my friends and family (always a good criterion for things you'd like to do to users). -Boris
Re: [whatwg] [URL] Starting work on a URL spec
On 7/24/2010 12:02 PM, Boris Zbarsky wrote: On 7/23/10 11:59 PM, Silvia Pfeiffer wrote: Is that URLs as values of attributes in HTML or is that URLs as pasted into the address bar? I believe their processing differs... It certainly does in Firefox (the latter have a lot more fixup done to them, and there are also differences in terms of how character encodings are handled). I would be particularly interested in data on this last, across different browsers, operating systems, and locales... There seem to be servers out there expecting their URIs in UTF-8 and others expecting them in ISO-8859-1, and it's not clear to me how to make things work with them all. Seems to me that if they are not in UTF-8, they should be treated as bugs, even if that is not a de jure standard. Brett
Re: [whatwg] [URL] Starting work on a URL spec
http://code.google.com/apis/safebrowsing/developers_guide_v2.html#Canonicalization lists some interesting cases we've come across on the anti-phishing team in Google. To the extent you're concerned with / interested in canonicalizaiton, it may be worth taking a look at (not to suggest you follow that in determining how to parse/canonicalize URLs, but rather to make sure that you have some "correct" way of handling the listed URLs). BTW, are you covering canonicalization? -Ian On Fri, Jul 23, 2010 at 9:02 PM, Boris Zbarsky wrote: > On 7/23/10 11:59 PM, Silvia Pfeiffer wrote: > >> Is that URLs as values of attributes in HTML or is that URLs as pasted >> into the address bar? I believe their processing differs... >> > > It certainly does in Firefox (the latter have a lot more fixup done to > them, and there are also differences in terms of how character encodings are > handled). > > I would be particularly interested in data on this last, across different > browsers, operating systems, and locales... There seem to be servers out > there expecting their URIs in UTF-8 and others expecting them in ISO-8859-1, > and it's not clear to me how to make things work with them all. > > -Boris >
Re: [whatwg] [URL] Starting work on a URL spec
On 7/23/10 11:59 PM, Silvia Pfeiffer wrote: Is that URLs as values of attributes in HTML or is that URLs as pasted into the address bar? I believe their processing differs... It certainly does in Firefox (the latter have a lot more fixup done to them, and there are also differences in terms of how character encodings are handled). I would be particularly interested in data on this last, across different browsers, operating systems, and locales... There seem to be servers out there expecting their URIs in UTF-8 and others expecting them in ISO-8859-1, and it's not clear to me how to make things work with them all. -Boris
Re: [whatwg] [URL] Starting work on a URL spec
Is that URLs as values of attributes in HTML or is that URLs as pasted into the address bar? I believe their processing differs... Good luck with it, anyway. I'm sure you've seen http://esw.w3.org/UriTesting . Cheers, Silvia. On Sat, Jul 24, 2010 at 5:11 AM, Adam Barth wrote: > I've begun working on a specification for how browsers process URLs: > > http://github.com/abarth/url-spec > > The repository is currently empty, but I'll be adding the basic > skeleton over the next few weeks. My intention is to triangulate > between how IE, Firefox, Chrome, Safari, and Opera process URLs to > find an algorithm that is both compatible with the web and moderately > sane. > > Please let me know if you know of any public URL parsing test suites. > My main starting point will be the WebKit URL parsing test suite, > > http://trac.webkit.org/browser/trunk/LayoutTests/fast/url > > which was adapted from the GURL parsing library. > > Thanks, > Adam >
Re: [whatwg] resource selection algorithm and NETWORK_NO_SOURCE
There is definitely a spec bug, because different locations of the spec say
diverging things. While the first step in the resource selection algorithm
states to go into NETWORK_NO_SOURCE state, the description of
NETWORK_NO_SOURCE in the spec actually implies a state of failure. Since the
first step in the resource selection algorithm really is a state where we
know nothing about the resource yet, it matches more with the description of
NETWORK_EMPTY:
NETWORK_EMPTY (numeric value 0)
The element has not yet been initialized. All attributes are in their
initial states.
NETWORK_NO_SOURCE (numeric value 3)
The element's resource selection algorithm is active, but it has failed
to find a resource to use.
In any case, it would be nice to get the spec corrected either way and the
implementations aligned. :)
Cheers,
Silvia.
On Sat, Jul 24, 2010 at 12:16 AM, Philip Jägenstedt wrote:
> Silvia made we aware of discrepancy in how browsers implement the resource
> selection algorithm, see forwarded message. It's my assessment that Opera is
> the only browser following the spec. I've filed this bug with Mozilla:
>
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=581355
>
> I've also reported bugs in Chrome and Safari, but can't see where they
> ended up.
>
> The reason I'm writing this email is that apparently everyone but myself
> has a different interpretation of the spec, so perhaps this is something we
> need to discuss. Does any other browser ever set the state NETWORK_NO_SOURCE
> at all? I speculated that perhaps other browsers aren't very strict about
> which parts of the algorithm are run synchronously and not, but even
> checking the networkState after a setTimeout it still isn't
> NETWORK_NO_SOURCE.
>
> Test case: http://people.opera.com/philipj/2010/07/23/networkState.html
>
> Please fix implementation or spec :)
>
>
> --
> Philip Jägenstedt
> Core Developer
> Opera Software
>
> --- Forwarded message ---
> From: "Silvia Pfeiffer"
> To: "Philip Jägenstedt"
> Cc:
> Subject: Re: bug in Opera video
> Date: Thu, 22 Jul 2010 12:51:15 +0200
>
> Hi Philip,
>
> On Thu, Jul 22, 2010 at 8:02 PM, Philip Jägenstedt
> wrote:
>
>> On Thu, 22 Jul 2010 01:23:09 +0200, Silvia Pfeiffer
>> wrote:
>>
>> Hi Philip,
>>>
>>> I've just made an experiment with the play() function in Opera and it
>>> seems that Opera doesn't support play() if currentSrc has not been
>>> determined yet (i.e. if the media element doesn't have a loaded
>>> resource). The spec says to deal with this situation and so do all
>>> other browsers, bar Opera. Here is a test:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> currentSrc on start: .
>>> currentSrc after loadedmetadata: >> id="currentSrc_loadedmetadata">.
>>>
>>> video = document.getElementsByTagName("video")[0];
>>> source = document.getElementsByTagName("source");
>>>
>>> span1 = document.getElementById("currentSrc_first");
>>> span1.innerHTML = video.currentSrc;
>>> source[0].src = "HelloWorld.mp4";
>>> source[1].src = "HelloWorld.webm";
>>> source[2].src = "HelloWorld.ogv";
>>> video.play();
>>>
>>> span2 = document.getElementById("currentSrc_loadedmetadata");
>>> function span2Update(evt) {
>>> span2.innerHTML = video.currentSrc;
>>> }
>>> video.addEventListener("loadedmetadata", span2Update, false);
>>>
>>>
>>>
>>>
>>> The video.play() function should execute the resource selection and
>>> fetching, but it doesn't. Not sure if this is deliberate and you want
>>> a discussion on the whatwg about it, or just a bug.
>>>
>>> Cheers,
>>> Silvia.
>>>
>>>
>> The spec says "If the media element's networkState attribute has the value
>> NETWORK_EMPTY, invoke the media element's resource selection algorithm."
>>
>> I added alert(video.networkState) just before video.play. In Opera it is 3
>> (NETWORK_NO_SOURCE) while in Chrome it is 0 (NETWORK_EMPTY).
>>
>
> Ah, yes, this is actually another thing I wanted to alert you to. All
> other browsers set the @networkState to NETWORK_EMPTY at the start of
> loading a new media resource (Firefox, Safari and Chrome). I was going
> to discuss this with you, since Opera interprets the spec different
> here - which is understandable, since the first step in the resource
> selection algorithm says to:
> 1. Set the networkState to NETWORK_NO_SOURCE.
>
> OTOH however, the description for the NETWORK_NO_SOURCE state is as
> follows:
> NETWORK_EMPTY (numeric value 0)
> The element has not yet been initialized. All attributes are in
> their initial states.
> and for NETWORK_NO_SOURCE is:
> NETWORK_NO_SOURCE (numeric value 3)
> The element's resource selection algorithm is active, but it has
> failed to find a resource to use.
>
> Thus, I believe this may be a spec bug and really the first step in
> the resource selection algorithm should say
> 1. Set the networkState to NETWORK_EMPTY.
> which is more consistent with the implementations of the other
> bro
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
> 99.% of people have never manually entered a javascript: URL > into a browser addressbar in their life -- unless duped by a social > engineering virus. Wrong. Plain wrong. Kids who like to test stuff do things like this. I do agree though that the urlbar isn't the right place, there should be a different prompt for this kind of stuff. Probably disabled at compile time by default and accessible by recompile (or addon).
Re: [whatwg] [URL] Starting work on a URL spec
On Fri, 23 Jul 2010 21:11:35 +0200, Adam Barth wrote: I've begun working on a specification for how browsers process URLs: http://github.com/abarth/url-spec The repository is currently empty, but I'll be adding the basic skeleton over the next few weeks. My intention is to triangulate between how IE, Firefox, Chrome, Safari, and Opera process URLs to find an algorithm that is both compatible with the web and moderately sane. Good luck ;) Seriously, it is probably worth looking at things like curl that are not browsers but consume URLs (and in turn are used by various systems that interact with URLs for things like software updates, synchronisation, etc). cheers Chaals -- Charles McCathieNevile Opera Software, Standards Group je parle français -- hablo español -- jeg lærer norsk http://my.opera.com/chaals Try Opera: http://www.opera.com
Re: [whatwg] Question about the application/x-www-form-urlencoded encoding algorithm
On Sun, 21 Mar 2010, NARUSE, Yui wrote: > (2010/01/21 16:29), NARUSE, Yui wrote: > > In 4.10.19.4 URL-encoded form data, The > > application/x-www-form-urlencoded encoding algorithm, > > it says: > > > > > For each character in the entry's name and value, apply the following > > > subsubsteps: > > > > > > If the character isn't in the range U+0020, U+002A, U+002D, U+002E, > > > U+0030 to U+0039, U+0041 to U+005A, U+005F, U+0061 to U+007A > > > then replace the character with a string formed as follows: > > > Start with the empty string, and then, taking each byte of the character > > > when expressed in the selected character encoding in turn, > > > append to the string a U+0025 PERCENT SIGN character (%) followed > > > by two characters in the ranges U+0030 DIGIT ZERO (0) to > > > U+0039 DIGIT NINE (9) and U+0041 LATIN CAPITAL LETTER A > > > to U+0046 LATIN CAPITAL LETTER F representing the hexadecimal value > > > of the byte (zero-padded if necessary). > > > > > > If the character is a U+0020 SPACE character, replace it with a single > > > U+002B PLUS SIGN character (+). > > > > This means, U+9670, encoded as "\x89\x41" in Shift_JIS, must be > > encoded as "%89%41", > > and shouldn't be "%89A"? > > The spec is read that > "\x89\x41" in Shift_JIS should be encoded as "%89%41". > But current impplementations encode it as "%89A". > (I tested IE, Firefox, Opera, Chrome) > > So this should be a bug of the spec. This is now fixed in the spec, by the way. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] resource selection algorithm and NETWORK_NO_SOURCE
On 24/07/2010 2:16 a.m., Philip Jägenstedt wrote: Silvia made we aware of discrepancy in how browsers implement the resource selection algorithm, see forwarded message. It's my assessment that Opera is the only browser following the spec. I've filed this bug with Mozilla: https://bugzilla.mozilla.org/show_bug.cgi?id=581355 Thanks, Firefox is not setting the networkState to NETWORK_NO_SOURCE when the synchronous part of the resource selection algorithm returns. We've not updated our load algorithm implementation in about a year, there will no doubt be other places where we're non-compliant. We've got an existing bug on file to update the load algorithm: https://bugzilla.mozilla.org/show_bug.cgi?id=485288 Walking on water and developing software from a specification are easy if both are frozen. Regards, Chris Pearce.
Re: [whatwg] HTMLMediaElement.preload and stalled event
On 23/07/2010 8:57 p.m., Philip Jägenstedt wrote: On Fri, 23 Jul 2010 05:25:37 +0200, Chris Pearce wrote: Should we be periodically firing a "stalled" event at the media element while we've suspended download of a preload:none or preload:metadata media? [...] I think this is a spec bug. When a UA decides to not download more data it should fire the suspend event. It doesn't make any sense to also fire the stalled event, in my opinion, but the spec isn't clear about this. I agree. We should make the spec clearer here. Also, I don't understand why the stalled event would be fired periodically in any case, why would that be so? Agreed, it doesn't make sense to fire multiple stalled events; you can detect when the download resumes by listening for subsequent progress events. On 23/07/2010 5:11 p.m., Silvia Pfeiffer wrote: To me, stalled implies that the UA is trying to receive stuff, but is being stalled. So, my understanding is that the resource fetch algorithm in [1] should include the word "unexpectedly" - that would fix it. I think this suggested wording change would be a good one. Regards, Chris Pearce.
Re: [whatwg] Constraint validation for maxlength
On Thu, Jul 22, 2010 at 5:46 PM, Jonas Sicking wrote: > I think that depends largely on how many, and how big, sites are > affected by this. Do you have a list of known sites with this issue? No, I was just raising the issue to see what people thought. Maybe someone from Opera could share a reason why they don't follow the spec here, unless the spec was different when they implemented it or something.
Re: [whatwg] several messages
On Thu, 18 Mar 2010, Alex Bishop wrote: > > In the processing model for image maps (section 4.8.13.2), step 8 of the > processing instructions for area elements says that if the shape > attribute is in the Circle state: > > > Let x be the first number in coords, y be the second number, and r be > > the third number. > > > > The shape is a circle whose center is x CSS pixels from the left edge > > of the image and x CSS pixels from the top edge of the image, and > > whose radius is r pixels. > > Surely "x CSS pixels from the top edge of the image" should read "y CSS > pixels from the top edge of the image"? On Thu, 18 Mar 2010, Ashley Sheridan wrote: > > I think the x here indicates an arbitrary number rather than units along > the y-axis. On Fri, 19 Mar 2010, Tab Atkins Jr. wrote: > > No, the first sentence of the quote Alex gives makes it clear that "x" > has a definite meaning, along with "y" and "r". The spec has a typo - > the distance from the top edge should indeed be "y" pixels, as that is > the second number in the @coords attribute. Fixed. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] several messages
On Thu, 18 Mar 2010, Simon Pieters wrote: > On Thu, 18 Mar 2010 01:03:33 +0100, Ian Hickson wrote: > > On Mon, 22 Feb 2010, Kornel Lesi�~Dski wrote: > > > > > > I'm wondering if data-* attributes should be renamed to priv-* to > > > make it clearer that it's page's _private_ data. > > > > > > "data-" is such a nice generic prefix that I'm afraid sooner or > > > later someone will start basing microformats-like markup on that. > > > > It's not a bad idea... Unfortunately data-* is already being used > > quite a lot and has been widely advertised, so we have to be careful > > with this. Anyone else have an opinion on this? > > I think we should keep data- as is. People have started to use it, we > would waste their time by renaming it. On Thu, 18 Mar 2010, Henri Sivonen wrote: > > > > I don't feel strongly that either name is better. Though I would not > > that priv- doesn't make things much clearer since it's totally > > undefined who it's private to. > > Given that priv-* isn't clearly better, I think it would be better not > to annoy early adopters of data-* with a name change. On Thu, 18 Mar 2010, Jonas Sicking wrote: > > Agreed. I haven't changed it. On Wed, 30 Jun 2010, Tab Atkins Jr. wrote: > > In the first paragraph of > http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data > > it says that a custom data attribute is "an attribute in no namespace > whose name starts with the string "data-", has at least one character > after the hyphen,...". Following this, would not put > anything in .dataset. > > However, in the algorithm for getting the list of name-value pairs, it > says to process "each content attribute on the element whose first five > characters are the string "data-" and whose remaining characters (if > any)...". Following this, would make > .dataset[""]="foo". > > One of these references needs to be fixed, as webkit is implementing > dataset right now. There's no contradiction here, it's just a difference between author conformance and implementation requirements in error conditions. Since WebKit implemented this as specced, I've left it unchanged: https://bugs.webkit.org/show_bug.cgi?id=41146 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] [URL] Starting work on a URL spec
On 7/23/10 3:11 PM, Adam Barth wrote: Please let me know if you know of any public URL parsing test suites. My main starting point will be the WebKit URL parsing test suite, There's a bit at http://mxr.mozilla.org/mozilla-central/source/netwerk/test/unit/test_standardurl.js I thought there was some other stuff there too, but can't find it at the moment. This only tests authority urls. -Boris
Re: [whatwg] Why not creating a category for elements candidate for constraint validation?
On Fri, Jul 23, 2010 at 10:01 AM, Mounir Lamouri wrote: > On 07/20/2010 04:07 PM, Simon Pieters wrote: >> On Tue, 20 Jul 2010 15:47:32 +0200, Mounir Lamouri >> wrote: >> >>> Hi, >>> >>> I'm wondering why there is no categories for elements candidate for >>> constraint validation. In the current state of the specs, all listed >>> elements are candidate for constraint validation except when they are >>> barred from constraint validation. Barring an element from constraint >>> validation when it is in a certain state seems good but having elements >>> always barred from constraint validation seems a bad idea. It makes them >>> having the entire constraint validation API for nothing. >>> >>> Wouldn't that be preferable to have the constraint validation API >>> implemented only on elements that can actually use it? I think it would >>> probably be less confusing. >>> >>> So, anyone knows if there is a reason (too much categories already? >>> easier describe in the specs?) to have this done this way or if it could >>> be possible to have this new category? >> >> I believe some elements have the API but are barred because it makes it >> easier to loop through form.elements and do the validation stuff without >> checking if the validation stuff is available on the element. (Same >> reason has .type.) > > But , , and are barred from > constraint validation and , , and are > not [1]. Half of the elements have a useless API, that sounds too much > for me. I think it's not so complicated to loop through the form > elements and checking if it implements a part of the constraint > validation api or checking the tag name. > > There is another reason why all these elements implement an API they do > not use? > > [1] In my opinion, should not be barred and should. > But that's another topic. It probably results in less code if a handful of implementations have to add a few stubbed functions, than if millions of pages all will have to check if constraint validation is there before using it. Not to mention that I trust you (a implementor) to get this right, a lot more than I trust thousands of webauthors to get this right. / Jonas
Re: [whatwg] Script-related feedback
On Wed, 17 Mar 2010, Steve Souders wrote: > > > > Given that it is possible to do this from script, how common is it for > > people to do it from script? If it's very common, that would be a good > > data point encouraging us to do this sooner rather than later. > > 6 of the top 10 US web sites load scripts after the load event: eBay, > Facebook, Bing, MSN.com, MySpace, and Yahoo. Do we know why they do this rather than use defer="", and whether defer="" would handle their use casess? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Element-related feedback
On Fri, Jul 23, 2010 at 11:54 AM, Ian Hickson wrote: > Most platforms have built-in mechanisms for showing dates and times in a > fashion of the user's chosing. I suggest using that. It may be that this > ends up being a lost cause, or that authors don't care about this, but I > think we should at least give it a shot. I'm reluctant to have an element > that does nothing visual and is just used for encoding data, since that is > likely to end up with a lot more bogus data than if it actually does > something. Fwiw, as an author, I certainly care about this, and like the ability to localize the display of the datetime. ~TJ
[whatwg] [URL] Starting work on a URL spec
I've begun working on a specification for how browsers process URLs: http://github.com/abarth/url-spec The repository is currently empty, but I'll be adding the basic skeleton over the next few weeks. My intention is to triangulate between how IE, Firefox, Chrome, Safari, and Opera process URLs to find an algorithm that is both compatible with the web and moderately sane. Please let me know if you know of any public URL parsing test suites. My main starting point will be the WebKit URL parsing test suite, http://trac.webkit.org/browser/trunk/LayoutTests/fast/url which was adapted from the GURL parsing library. Thanks, Adam
Re: [whatwg] Element-related feedback
On Tue, 16 Mar 2010, Philip Jägenstedt wrote: > On Tue, 16 Mar 2010 17:01:00 +0800, Ian Hickson wrote: > > On Mon, 16 Nov 2009, Philip Jägenstedt wrote: > > > > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-time-element-0 > > > > > > "When the time binding applies to a time element, the element is > > > expected to render as if it contained text conveying the date (if > > > known), time (if known), and time-zone offset (if known) represented > > > by the element, in the fashion most convenient for the user." > > > > > > This is very vague. Anything which tries to localize the date/time > > > will fail because guessing the language of web pages is hard. > > > Hard-coding it to English also wouldn't be very nice. What seems to > > > make the most sense is using the "best representation of the global > > > date and time string" and equivalents for just time and date that > > > have to be defined. Still, I'm not sure this is very useful, as the > > > same rendering (but slightly more flexible) could be accomplished by > > > simply putting the date/time in the content instead of in the > > > attribute. As a bonus, that would degrade gracefully. Unless I'm > > > missing something, I suggest dropping the special rendering > > > requirements for completely. > > > > The idea is to render the date or time in the user's locale, not the > > page's, though I agree that in some cases that could be confusing. > > > > Maybe we should leave the localising behaviour to author CSS and not > > do it automatically by default? > > I think that would be better, yes. Either that or a spec saying exactly > what string to output for each possible locale. (Making it platform- and > browser-dependent is just asking for trouble.) I haven't changed this at this point because it would leave the element as rendering nothing when the contents of the element are empty and the author has only provided an attribute. Most platforms have built-in mechanisms for showing dates and times in a fashion of the user's chosing. I suggest using that. It may be that this ends up being a lost cause, or that authors don't care about this, but I think we should at least give it a shot. I'm reluctant to have an element that does nothing visual and is just used for encoding data, since that is likely to end up with a lot more bogus data than if it actually does something. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
I second that call. While your suggestion seems to prevent some existing social engineering, you must realize that HTML5 isn't going to be recommended until ~2020. By that time, everything we talk about social engineering today will be completely obsolete. Things like this are best left to be taken care by UA vendors. I suggest that you write a formal request and send it to major UA vendors such as Apple, Google, Microsoft, Opera, etc... On Fri, Jul 23, 2010 at 8:26 AM, João Eiras wrote: > On Thu, 22 Jul 2010 21:32:39 +0100, Luke Hutchison > wrote: > > [snip] >> >> Comments, please? >> > > This is entirely out of scope of any specification and 100% an user agent > UI issue. > >
Re: [whatwg] Why not creating a category for elements candidate for constraint validation?
On 07/20/2010 04:07 PM, Simon Pieters wrote: > On Tue, 20 Jul 2010 15:47:32 +0200, Mounir Lamouri > wrote: > >> Hi, >> >> I'm wondering why there is no categories for elements candidate for >> constraint validation. In the current state of the specs, all listed >> elements are candidate for constraint validation except when they are >> barred from constraint validation. Barring an element from constraint >> validation when it is in a certain state seems good but having elements >> always barred from constraint validation seems a bad idea. It makes them >> having the entire constraint validation API for nothing. >> >> Wouldn't that be preferable to have the constraint validation API >> implemented only on elements that can actually use it? I think it would >> probably be less confusing. >> >> So, anyone knows if there is a reason (too much categories already? >> easier describe in the specs?) to have this done this way or if it could >> be possible to have this new category? > > I believe some elements have the API but are barred because it makes it > easier to loop through form.elements and do the validation stuff without > checking if the validation stuff is available on the element. (Same > reason has .type.) But , , and are barred from constraint validation and , , and are not [1]. Half of the elements have a useless API, that sounds too much for me. I think it's not so complicated to loop through the form elements and checking if it implements a part of the constraint validation api or checking the tag name. There is another reason why all these elements implement an API they do not use? [1] In my opinion, should not be barred and should. But that's another topic. Thanks, -- Mounir
Re: [whatwg] Canvas stroke alignment
Nice, less math.
I think the outside alignment approach will only work on paths that have
a 100% opacity fill.
The off-screen rectangle approach could work with opacity but it has the
same problem with transparent pixels between the stroke and the fill as
you'd get with a custom path once it curves.
It would be nice if Canvas took care of stroke alignment so we can get
rid of the hacks and limitations those bring along.
--
Nick
Op 20-7-2010 19:36, David Flanagan schreef:
Nick wrote:
Canvas would benefit from a way to set stroke alignment. With the
only available alignment being center, which is not very useful,
custom paths have to be drawn to mimic inside and outside stroke
alignment. That workaround may give unwanted transparency on pixels
between a path and its stroke path once a path goes diagonal or curves.
Having Canvas take care of stroke alignment (center, inside and
outside) by adding something like strokeAlign can fix these
transparency problems and makes adding strokes a lot easier and more
useful.
--
Nick Stakenburg
Currently for inside alignment, I think you can do this, with no
computation of custom path:
c.save();
c.clip();
c.lineWidth *= 2;
c.stroke();
c.restore();
Outside alignment is easy if you're also going to fill the path, of
course. But if you want to leave the inside of the path untouched you
could do something like this, I think:
var url = canvas.toDataURL(); // Back up canvas content
var img = document.createElement("img");
img.src = url;
c.save();
c.linewidth *= 2;
c.stroke();
c.clip();
c.drawImage(img, 0, 0); // Restore original bitmap inside the path
c.restore();
You can't use getImageData()/putImageData() for this, since they
ignore the clipping region.
Another approach for outside stroke alignment, if you know the
directionality of your path would be to turn the path inside out by
drawing an off-screen rectangle around the canvas in the opposite
direction. Then the outside of your path becomes the inside of the
new path and you can use the technique above for inside alignment...
David
Re: [whatwg] Please disallow "javascript:" URLs in browser address bars
On Thu, 22 Jul 2010 21:32:39 +0100, Luke Hutchison wrote: [snip] Comments, please? This is entirely out of scope of any specification and 100% an user agent UI issue.
[whatwg] resource selection algorithm and NETWORK_NO_SOURCE
Silvia made we aware of discrepancy in how browsers implement the resource
selection algorithm, see forwarded message. It's my assessment that Opera
is the only browser following the spec. I've filed this bug with Mozilla:
https://bugzilla.mozilla.org/show_bug.cgi?id=581355
I've also reported bugs in Chrome and Safari, but can't see where they
ended up.
The reason I'm writing this email is that apparently everyone but myself
has a different interpretation of the spec, so perhaps this is something
we need to discuss. Does any other browser ever set the state
NETWORK_NO_SOURCE at all? I speculated that perhaps other browsers aren't
very strict about which parts of the algorithm are run synchronously and
not, but even checking the networkState after a setTimeout it still isn't
NETWORK_NO_SOURCE.
Test case: http://people.opera.com/philipj/2010/07/23/networkState.html
Please fix implementation or spec :)
--
Philip Jägenstedt
Core Developer
Opera Software
--- Forwarded message ---
From: "Silvia Pfeiffer"
To: "Philip Jägenstedt"
Cc:
Subject: Re: bug in Opera video
Date: Thu, 22 Jul 2010 12:51:15 +0200
Hi Philip,
On Thu, Jul 22, 2010 at 8:02 PM, Philip Jägenstedt
wrote:
On Thu, 22 Jul 2010 01:23:09 +0200, Silvia Pfeiffer
wrote:
Hi Philip,
I've just made an experiment with the play() function in Opera and it
seems that Opera doesn't support play() if currentSrc has not been
determined yet (i.e. if the media element doesn't have a loaded
resource). The spec says to deal with this situation and so do all
other browsers, bar Opera. Here is a test:
currentSrc on start: .
currentSrc after loadedmetadata: .
video = document.getElementsByTagName("video")[0];
source = document.getElementsByTagName("source");
span1 = document.getElementById("currentSrc_first");
span1.innerHTML = video.currentSrc;
source[0].src = "HelloWorld.mp4";
source[1].src = "HelloWorld.webm";
source[2].src = "HelloWorld.ogv";
video.play();
span2 = document.getElementById("currentSrc_loadedmetadata");
function span2Update(evt) {
span2.innerHTML = video.currentSrc;
}
video.addEventListener("loadedmetadata", span2Update, false);
The video.play() function should execute the resource selection and
fetching, but it doesn't. Not sure if this is deliberate and you want
a discussion on the whatwg about it, or just a bug.
Cheers,
Silvia.
The spec says "If the media element's networkState attribute has the
value
NETWORK_EMPTY, invoke the media element's resource selection algorithm."
I added alert(video.networkState) just before video.play. In Opera it is
3
(NETWORK_NO_SOURCE) while in Chrome it is 0 (NETWORK_EMPTY).
Ah, yes, this is actually another thing I wanted to alert you to. All
other browsers set the @networkState to NETWORK_EMPTY at the start of
loading a new media resource (Firefox, Safari and Chrome). I was going
to discuss this with you, since Opera interprets the spec different
here - which is understandable, since the first step in the resource
selection algorithm says to:
1. Set the networkState to NETWORK_NO_SOURCE.
OTOH however, the description for the NETWORK_NO_SOURCE state is as
follows:
NETWORK_EMPTY (numeric value 0)
The element has not yet been initialized. All attributes are in
their initial states.
and for NETWORK_NO_SOURCE is:
NETWORK_NO_SOURCE (numeric value 3)
The element's resource selection algorithm is active, but it has
failed to find a resource to use.
Thus, I believe this may be a spec bug and really the first step in
the resource selection algorithm should say
1. Set the networkState to NETWORK_EMPTY.
which is more consistent with the implementations of the other
browsers and also consistent with the meaning of NETWORK_EMPTY and
NETWORK_NO_SOURCE.
We are
following the spec here, as the resource selection algorithm should be
run
the first time when the video element is inserted into the DOM by the
parser, then again after each source element is inserted. For this
markup,
it will stay as NETWORK_NO_SOURCE in all cases, which is basically a
waiting
state.
There are a few ways we could go about solving this:
1. Make modifying the src attribute of source elements that are children
to
a video element that has state EMPTY or NO_SOURCE run the resource
selection
algorithm. I don't like this idea myself, it's unnecessarily complicated.
2. Let the other browsers follow the spec and add a call to video.load()
before video.play().
Please do bring this up with the WHATWG. If you like you can forward this
mail verbatim. To anyone testing this, note that HelloWorld.mp4 has to
actually exist (or changed to something that does) for the above test to
work.
Actually, in cases where it doesn't exist, all other browsers can deal
with it, but Opera hangs. I have actually posted that to Opera bug
reports if you want to follow up on this, too.
Re: [whatwg] Timed tracks for
On Jul 23, 2010, at 08:40, Ian Hickson wrote: > I recently added to the HTML spec a mechanism by which external subtitles > and captions can be added to videos in HTML. Thanks! I like most parts of the new mechanism. I'm commenting just on what I think should be changed, but please don't read this as being overall negative. > - A set of rules and processing models to hold it all together. Is it intentional that WebSRT doesn't come with any examples? > - Keep implementation costs for standalone players low. I think this should be a non-goal. It seems to me that trying to cater for non-browser user agents or non-Web uses in Web specs leads to bad Web specs. I think by optimizing for standalone players WebSRT falls into one of the common traps for Web specs. I think we should design for the Web (where the rendering is done by browser engines). > - Use existing technologies where appropriate. [...] > - Try as much as possible to have things Just Work. I think by specifying a standalone cue text parser WebSRT fails on these counts compared to reusing the HTML fragment parsing algorithm for parsing cue text. Specifying a new parser for turning HTML-like tags into a tree structure that can be used as the input of a CSS formatter fails to reuse existing technologies where appropriate (though obviously we disagree on what's "appropriate"). Supporting only some tags and failing to support from existing .srt fails on "Just Work" in two ways: Existing .srt doesn't Just Work and trying stuff that one would expect to work given that the markup looks like HTML doesn't "Just Work". > I first researched (with some help from various other contributors - > thanks!) what kinds of timed tracks were common. The main classes of use > cases I tried to handle were plain text subtitles (translations) and > captions (transcriptions) with minimal inline formatting and karaoke > support, chapter markers so that browsers could provide quick jumps to > points in the video, text-driven audio descriptions, and application- > specific timed data. Why karaoke and application-specific data? Those both seem like feature creep compared to the core cases of subtitles and captions. > If we don't use HTML wholesale, then there's really no reason to use HTML > at all. (And using HTML wholesale is not really an option, as you say > above.) I disagree. The most obvious way of reusing existing infrastructure in browsers, the most obvious way of getting support for future syntax changes that support attributes or new tag names and the most obvious way to get error handling that behaves in the way the appearance of the syntax suggests is to reuse the HTML fragment parsing algorithm for parsing the cue text. > On Thu, 16 Jul 2009, Philip Jägenstedt wrote: >> >> There are already more formats than you could possibly want on the scale >> between SRT (dumb text) and complex XML formats like DFXP or USF (used >> in Matroska). > > Indeed. I tried to examine all of them, but many had no documentation that > I could find. The results are in the wiki page cited above. Using the WebSRT container to transfer potentially arbitrary HTML has the benefit of scaling down as well as (Web)SRT while also scaling up to pretty much anything (esp. with SVG-in-HTML). > I've defined some CSS extensions to allow us to use CSS with SRT. The new CSS pseudos would be unnecessary if each cue formed a DOM by parsing "" as HTML (to get a skeleton DOM in the standards mode) and then document.body.innerHTML were set to the cue text. This way, to style the entire cue, the author would select html or body. There'd be no need for ::cue. Likewise, there'd be no need for the ::cue-part stuff if the voice became the className of either the root of body and the rest of cue settings were set as attributes (on root or body). >> Further, SRT has no way to specify which language it is written in > > What's the use case? CJK font selection. Also speech generator language selection if timed text is used to drive synthetic audio description. >> I actually quite like the general idea behind Silvia's >> http://wiki.xiph.org/Timed_Divs_HTML >> >> This is somewhat similar to the proposal that David Singer >> and Eric Carlson from Apple have brought up a few times. > > I am very reluctant to have such a verbose format be used for such dense > data files as captions. It works for HTML because the use of markup is > balanced with the text (though it can get pretty borderline, e.g. the HTML > spec itself has a high ratio of markup to text). It's not a nice format > for more dense data, IMHO. I agree. Furthermore, the WebSRT container is better suited for multiplexing the same captioning format into the video file, because it doesn't have a root element and it doesn't create the expectation that the entire Timed DIV markup exists in a stylable DOM at a time. If Timed DIVs were multiplexed into a video file, the solution would need t
Re: [whatwg] Timed tracks for
On Fri, 23 Jul 2010 07:40:57 +0200, Ian Hickson wrote: I recently added to the HTML spec a mechanism by which external subtitles and captions can be added to videos in HTML. Thanks for all the time spent putting this together, now it's our turn to review it to pieces again :) [snip] On Thu, 16 Jul 2009, Philip Jägenstedt wrote: In my layman opinion both extremes make sense, but anything in between I'm rather skeptical to. Is the SRT variant described in the spec extreme enough to make sense? It's hard to quantify, I'll simply criticize the things I don't like below. Generally, given , you have the tools to go as extreme as you want with scripts, SVG and CSS, at the cost of only working inside a web browser. As far as I can tell no browser wants to implement the addCueRange API (removing this should be the topic of a separate mail), so we really need to re-think this part and I think that timed text plays an important part here. The addCueRange() API has been removed and replaced with a feature based on the subtitle mechanism. Without having reviewed this in detail, I'm pretty happy with how it turned out. I'm not a fan of pauseOnExit, though, mostly because it seems non-trivial to implement. Since it is last in the argument list of TimedTrackCue, it will be easy to just ignore when implementing. I still don't think the use cases for it are enough to motivate the implementation cost. On Fri, 31 Jul 2009, Silvia Pfeiffer wrote: * It is unclear, which of the given alternative text tracks in different languages should be displayed by default when loading an resource. A @default attribute has been added to the elements to allow for the Web content author to tell the browser which tracks he/she expects to be displayed by default. If the Web author does not specify such tracks, the display depends on the user agent (UA - generally the Web browser): for accessibility reasons, there should be a field that allows users to always turn display of certain categories on. Further, the UA is set to a default language and it is this default language that should be used to select which track should be displayed. It's not clear to me that we need a way to do this; by default presumably tracks would all be off unless the user wants them, in which case the user's preferences are paramount. That's what I've specced currently. However, it's easy to override this from script. It seems to me that this is much like in that if we don't provide a markup solution, everyone will use scripts and it will be more difficult for the UA to override with user prefs. On Fri, 31 Jul 2009, Philip Jägenstedt wrote: * Security. What restrictions should apply for cross-origin loading? Currently the files have to be same-origin. My plan is to wait for CORS to be well established and then use it for timed tracks, video files, images on , text/event-stream resources, etc. If I'm interpreting the track fetch algorithm correctly cross-origin is strictly enforced and treated as a network error. This is different from e.g. and , but it seems to make things simpler, so I'm fine with that. It also ensures that JavaScript fallback handling of won't fail just because of cross-origin in XHR. * Complexity. There is no limit to the complexity one could argue for (bouncing ball multi-color karaoke with fan translations/annotations anyone?). We should accept that some use cases will require creative use of scripts/SVG/etc and not even try to solve them up-front. Draw a line and stick to it. Agreed. Hopefully you agree with where I drew the line! :-) Actually, I think both karaoke (in-cue timestamps) and ruby are borderline, but it depends on how difficult it is to implement. One thing in particular to note about karaoke is that even with in-cue timestamps, CSS still won't be enough to get the typical effect of "wiping" individual characters from one style to another, since the smallest unit you can style is a single character. To get that effect you'd have to render the characters in two styles and then cut them together (with or just clipping s). Arguably, this is a presentation issue that could be fixed without changing WebSRT. On Thu, 15 Apr 2010, Silvia Pfeiffer wrote: Further, SRT has no way to specify which language it is written in What's the use case? As hints for font selection and speech synthesis. On Thu, 15 Apr 2010, Philip Jägenstedt wrote: While I don't favor TTML, I also don't think that extending SRT is a great way forward, mostly because I don't see how to specify the language (which sometimes helps font selection), That's done in the element. It can't be in the file, since you need to know it before downloading the file (otherwise you'd have to download all the files to update the UI). Good enough. Multi-lingual subtitles are still a problem, but also very rare (the only ones I've seen are those that I wrote myself). ap
Re: [whatwg] Timed tracks for
On Fri, Jul 23, 2010 at 1:00 AM, Ian Hickson wrote: > On Fri, 23 Jul 2010, Jonas Sicking wrote: >> > >> > The WebSRT stuff itself is pretty modular, it's just two sections: >> > >> > http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#websrt-0 >> > http://www.whatwg.org/specs/web-apps/current-work/complete/rendering.html#timed-tracks-0 >> >> That is good to know, though it's unfortunate that this has to be asked >> and isn't obvious by reading the spec. > > It's _somewhat_ obvious; it's the only sections with "WebSRT" in their > name in the table of contents. :-) > > Never wanting to be the one getting in the way of your happiness, though, > I hereby present you with the WebSRT sections of the HTML spec extracted > for your pleasure: > > http://www.whatwg.org/specs/web-apps/current-work/websrt.html > > HTH. Yay! It definitely! >> > In the meantime, the main place to start right now is the syntax of >> > the WebSRT file, which is defined separate from the parser: >> > >> > http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#syntax-0 >> >> Good to know that this is on the way. I tried reading the section you >> are quoting, but it was still more work than I have feel like I have >> time for, especially given that I'm not an expert on timed text. I >> suspect I'll just end up waiting until the introductory sections are >> available. > > Right-o. Shouldn't be too long. Is there anything else that would help > with any implementation work, should it prove to be implementation-worthy? > Other than a test suite, that is. I'll have to do more reviewing. Will let you know if I find anything. / Jonas
Re: [whatwg] HTMLMediaElement.preload and stalled event
On Fri, 23 Jul 2010 05:25:37 +0200, Chris Pearce wrote: I am implementing HTMLMediaElement.preload in Firefox, and I have a question: Should we be periodically firing a "stalled" event at the media element while we've suspended download of a preload:none or preload:metadata media? In step 2 of the resource fetch algorithm [1], the spec says "If at any point the user agent has received no data for more than about three seconds, then queue a task to fire a simple event named stalled at the element." But the description of the "stalled" event [2] says "The user agent is trying to fetch media data, but data is unexpectedly not forthcoming." The later description seems to imply that we only send "stalled" events when we unexpectedly stop receiving data, but the resource fetch algorithm indicates we should send "stalled" events if we stop receiving data for any reason, even if we suspend the download, and thus expect to not receive data. If we should send the stalled events, we should update the description of the stalled event at [2] to reflect that. Thanks, Chris Pearce. [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#event-media-stalled I think this is a spec bug. When a UA decides to not download more data it should fire the suspend event. It doesn't make any sense to also fire the stalled event, in my opinion, but the spec isn't clear about this. Also, I don't understand why the stalled event would be fired periodically in any case, why would that be so? -- Philip Jägenstedt Core Developer Opera Software
Re: [whatwg] application/octet-stream
On Thu, 22 Jul 2010 22:40:44 +0200, Maciej Stachowiak
wrote:
On Jul 22, 2010, at 3:30 AM, Philip Jägenstedt wrote:
On Thu, 22 Jul 2010 11:22:45 +0200, Henri Sivonen
wrote:
Chris Double wrote:
As I mentioned in a previous email, the sniffing could result in a
reasonable amount of data being consumed. I'm sure people who run
sites that share HTML 5 video would appreciate browsers not consuming
data bandwidth to sniff files that they've already specified as being
something the browser doesn't support.
I think the solution to this concern is to allow authors of
bandwidth-sensitive to specify the type attribute on or the
Content-Type header on the HTTP response to say something other than
application/octet-stream or text/plain. For best performance, authors
should use the type attribute in multi- cases anyway.
Chrome and Safari ignore the MIME type altogether, in my opinion if we
align with that we should do it full out, not just by adding text/plain
to the whitelist, as that would either require (a)
canPlayType("text/plain") to return "maybe" or (b) different code paths
for checking the MIME type in Content-Type and for canPlayType.
I don't think canPlayType("text/plain") has to return "maybe". It's not
useful for a Web developer to test for the browser's ability to sniff
to overcome a bad MIME type. canPlayType should be thought of as testing
whether the browser could play a media resource that is "really" of a
given type, rather than labeled with that type over HTTP.
Right, it certainly isn't useful, I'm just pointing out that this is what
happens if one adds text/plain to the list of "maybe" codecs rather than
ignoring Content-Type altogether, which is the only thing you can do
within the bounds of the current spec to get text/plain to play. The only
3 serious options I know are still the ones I outlined in my earlier email.
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] Timed tracks for
On Fri, 23 Jul 2010, Jonas Sicking wrote: > > > > The WebSRT stuff itself is pretty modular, it's just two sections: > > > > http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#websrt-0 > > > > http://www.whatwg.org/specs/web-apps/current-work/complete/rendering.html#timed-tracks-0 > > That is good to know, though it's unfortunate that this has to be asked > and isn't obvious by reading the spec. It's _somewhat_ obvious; it's the only sections with "WebSRT" in their name in the table of contents. :-) Never wanting to be the one getting in the way of your happiness, though, I hereby present you with the WebSRT sections of the HTML spec extracted for your pleasure: http://www.whatwg.org/specs/web-apps/current-work/websrt.html HTH. > > In the meantime, the main place to start right now is the syntax of > > the WebSRT file, which is defined separate from the parser: > > > > http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#syntax-0 > > Good to know that this is on the way. I tried reading the section you > are quoting, but it was still more work than I have feel like I have > time for, especially given that I'm not an expert on timed text. I > suspect I'll just end up waiting until the introductory sections are > available. Right-o. Shouldn't be too long. Is there anything else that would help with any implementation work, should it prove to be implementation-worthy? Other than a test suite, that is. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Timed tracks for
On Thu, Jul 22, 2010 at 11:31 PM, Ian Hickson wrote: > On Thu, 22 Jul 2010, Jonas Sicking wrote: >> >> Based on your email, this sounds like a very interesting format. >> However I can't really be certain due to two issues: >> >> 1. Reviewing the format by reading the parsing specification is >> basically impossible. Basically requires comming up with random >> inputs, stepping through the specification for each input, until I see >> patterns in the output. This will take more time than I have >> available. It's also likely that I'll miss several patterns. >> 2. In order to ensure that I've read all the parts related to WebSRT I >> need to read the full HTML spec. While this is something I'm in the >> process of doing, it'll probably take me months before I'm done. >> >> In short, I'd love to see WebSRT be written as a separate spec, with >> sections (non-normative if needed) that contain more human readable >> information about the format. > > The WebSRT stuff itself is pretty modular, it's just two sections: > > > http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#websrt-0 > > http://www.whatwg.org/specs/web-apps/current-work/complete/rendering.html#timed-tracks-0 That is good to know, though it's unfortunate that this has to be asked and isn't obvious by reading the spec. A related question is how will I find out if this list changes. I think making these sections available as a separate spec will significantly increase the number of people that will review it. Is there a reason not to, given that, as I understand it, there is tool support for producing separate spec documents. > The lack of introductory material and examples is absolutely a problem and > I have every intention of adding much such material in the near future. I > apologise for not having it already written; I generally delay writing the > introductory material until after zcorpan, hsivonen, jgraham, Philip`, > annevk, and others have looked at the spec, so that I don't have to > rewrite the introductory material several times as it tracks the changes > resulting from the major bugs they find. :-) > > In the meantime, the main place to start right now is the syntax of the > WebSRT file, which is defined separate from the parser: > > > http://www.whatwg.org/specs/web-apps/current-work/complete/video.html#syntax-0 Good to know that this is on the way. I tried reading the section you are quoting, but it was still more work than I have feel like I have time for, especially given that I'm not an expert on timed text. I suspect I'll just end up waiting until the introductory sections are available. / Jonas
