Re: [whatwg] Simon's WebSocket feedback
On Thu, 15 Apr 2010 03:08:12 +0200, Ian Hickson wrote: On Mon, 12 Apr 2010, Simon Pieters wrote: WebSocket establish a WebSocket connection: [[ 21. Insert spaces1 U+0020 SPACE characters into key1 at random positions. Insert spaces2 U+0020 SPACE characters into key2 at random positions. ]] It seems a bit risky to insert spaces at the start and at the end of the string; I imagine some servers would ignore them (which would be a bug in the server, but hard to notice since it's random). Maybe we should avoid inserting them at the start and at the end. Since key1 and key2 can be numbers in the range 1-9, I don't see how to avoid at least one of those two places. You can insert the random characters before inserting the spaces. -- Simon Pieters Opera Software
Re: [whatwg] Introduction of media accessibility features
On Wed, Apr 14, 2010 at 9:00 PM, Silvia Pfeiffer wrote: > On Thu, Apr 15, 2010 at 1:08 PM, Jonas Sicking wrote: >> On Wed, Apr 14, 2010 at 5:59 PM, Silvia Pfeiffer >> wrote: >>> On Thu, Apr 15, 2010 at 3:19 AM, Tab Atkins Jr. >>> wrote: >>> >>> If TTML creates specs that cannot be mapped, then those are ignored. >>> All we are basically committing to would be that a best effort is done >>> on the mapping. Just like with SRT we would do a best effort on the >>> mapping - there are SRT files now that have more than just plain text >>> in them. But we would not commit to interpreting every special markup >>> that some author came up with that worked in his particular player. >>> >>> I think the dependencies between external timed text formats and HTML5 >>> are much less than e.g. the dependency on SVG. TTML is not supposed to >>> be a native Web format in my eyes. It is just interpreted for the Web. >> >> I'm not sure I understand what you mean by "TTML is not supposed to be >> a native Web format"? Once browsers add support for it, it becomes a >> native web format. > > Would you call SRT a native Web format, too? If we were to implement it directly in browsers, yes. > Are RSS and ATOM native Web formats? Most definitely. I guess it comes down to a matter of definition of "native web format". As a browser implementor I think of it as anything that I have to implement and maintain to the level of quality that we want the web to work. As a web author I think of it as any format that I am able to use. >> No matter if the implementation behind the scenes >> map xsl:fo to CSS or through some other means. Netscape 4 implemented >> CSS by mapping it to JSSS [1], however for all any web developer ever >> knew, Netscape 4 supported CSS. Poorly. > > CSS is much tighter linked to HTML than a timed text format. If your > UA happens to not support TTML, only one feature will be missing, i.e. > timed text on your video. That doesn't destroy your Web page. But lack > of CSS support does. I guess I don't fully agree with you, but I think we've gotten side tracked as I don't think this matters to the question at hand. >> I really do hate to come up with a new format. But I think TTML is >> severely off the mark for what we want. Am I wrong in that marking up >> dialogue vs. sound effects vs. narrator vs. descriptions is important? >> Or at least more useful than for example the ability to set the text >> outline blur radius? > > I don't think your requirement is off the mark. I think it is > something that current caption formats don't do, since there hasn't > been a need and nobody has really looked at them from a Web > background. Therefore it wasn't included in TTML. I also have multiple > requirements that are not satisfied by TTML. I was under the > impression that we can fix up TTML with such extensions. But if people > prefer to develop a new format, that's fine by me. > > That doesn't mean though that we can ignore TTML. For what it has been > developed - for use in captions in all sorts of environment, which > include for example digital TV and mobile devices - it has been good > and its use is spreading. That's unfortunate to hear indeed. If there is a substantial body of content produced in TTML, and this body of content gets published on the web, then I agree that we indeed will have to reconsider. / Jonas
Re: [whatwg] Proposal for secure key-value data stores
On Wed, Apr 14, 2010 at 5:23 PM, Nicholas Zakas wrote: > I tried to articulate some of my thoughts as to why a generate purpose > crypto isn’t enough to be useful and why trying to tack onto local storage > could get messy: > > http://www.nczonline.net/blog/2010/04/13/towards-more-secure-client-side-data-storage/ I guess I don't understand why you think trying to tack it onto local storage could get messy. As you present it it would be messy, but AFAICT it wouldn't be all that hard to write a JavaScript wrapper which implements substantially the secure-storage interface you propose using local-storage as a backend. Doing it native would be faster and perhaps more secure, but in terms of proving out the interface itself those aren't really relevant. -scott
Re: [whatwg] Introduction of media accessibility features
On Thu, Apr 15, 2010 at 1:08 PM, Jonas Sicking wrote: > On Wed, Apr 14, 2010 at 5:59 PM, Silvia Pfeiffer > wrote: >> On Thu, Apr 15, 2010 at 3:19 AM, Tab Atkins Jr. wrote: >> >> If TTML creates specs that cannot be mapped, then those are ignored. >> All we are basically committing to would be that a best effort is done >> on the mapping. Just like with SRT we would do a best effort on the >> mapping - there are SRT files now that have more than just plain text >> in them. But we would not commit to interpreting every special markup >> that some author came up with that worked in his particular player. >> >> I think the dependencies between external timed text formats and HTML5 >> are much less than e.g. the dependency on SVG. TTML is not supposed to >> be a native Web format in my eyes. It is just interpreted for the Web. > > I'm not sure I understand what you mean by "TTML is not supposed to be > a native Web format"? Once browsers add support for it, it becomes a > native web format. Would you call SRT a native Web format, too? Are RSS and ATOM native Web formats? > No matter if the implementation behind the scenes > map xsl:fo to CSS or through some other means. Netscape 4 implemented > CSS by mapping it to JSSS [1], however for all any web developer ever > knew, Netscape 4 supported CSS. Poorly. CSS is much tighter linked to HTML than a timed text format. If your UA happens to not support TTML, only one feature will be missing, i.e. timed text on your video. That doesn't destroy your Web page. But lack of CSS support does. > I really do hate to come up with a new format. But I think TTML is > severely off the mark for what we want. Am I wrong in that marking up > dialogue vs. sound effects vs. narrator vs. descriptions is important? > Or at least more useful than for example the ability to set the text > outline blur radius? I don't think your requirement is off the mark. I think it is something that current caption formats don't do, since there hasn't been a need and nobody has really looked at them from a Web background. Therefore it wasn't included in TTML. I also have multiple requirements that are not satisfied by TTML. I was under the impression that we can fix up TTML with such extensions. But if people prefer to develop a new format, that's fine by me. That doesn't mean though that we can ignore TTML. For what it has been developed - for use in captions in all sorts of environment, which include for example digital TV and mobile devices - it has been good and its use is spreading. Cheers, Silvia.
Re: [whatwg] Introduction of media accessibility features
On Thu, Apr 15, 2010 at 12:24 PM, Tab Atkins Jr. wrote: > On Wed, Apr 14, 2010 at 5:59 PM, Silvia Pfeiffer > wrote: >> If TTML creates specs that cannot be mapped, then those are ignored. >> All we are basically committing to would be that a best effort is done >> on the mapping. Just like with SRT we would do a best effort on the >> mapping - there are SRT files now that have more than just plain text >> in them. But we would not commit to interpreting every special markup >> that some author came up with that worked in his particular player. >> >> I think the dependencies between external timed text formats and HTML5 >> are much less than e.g. the dependency on SVG. TTML is not supposed to >> be a native Web format in my eyes. It is just interpreted for the Web. > > "Best effort" mapping won't be enough as soon as this gets really > picks up. Authors can be crazy about the placement of things. We'll > end up having to define the exact mapping, or else have compat bugs on > all the browsers. As already stated: we will need a defined mapping that browsers adhere do. This mapping, however, does not need to embrace all TTML features. We just commit to implementing only those features in the mapping and then authors are very clear on what is supported and what is not. Even if we define a new format (which I am increasingly warming up to), I think we will still need to do this mapping. Otherwise, some browsers will implement support for TTML (I'm thinking in particular IE, since MS already supports DFXP in Silverlight, see http://www.w3.org/2009/05/dfxp-results.html) and others won't and then we end up in the mess that you are describing. I think TTML is that important in professional captioning applications that we can't ultimately avoid it. >> A spec would need to be written for this new extended SRT format. >> Also, if we are introducing HTML markup inside SRT time cues, then it >> would make sense to turn the complete SRT file into markup, not just >> the part inside the time cue. Further, SRT has no way to specify which >> language it is written in and further such general mechanisms that >> already exist for HTML. >> >> I don't think SRT is the right base format to start extending from. >> That extension doesn't give us anything anyway, since no existing SRT >> application would be able to do much with it. It is not hard to >> replicate the SRT functionality in something new. If we really want to >> do "SRT + HTML + CSS", then we should start completely from a blank >> page. > > I'm sympathetic to this sentiment. SRT seems to be the simplest > widespread format that would "just work", so extending it for the > other cases just feels like a potential win. But it might not be, > sure. > > Random brainstorm: we already had an element meant to mark up > dialogues, . Perhaps we can revive it, give it the minimal > extensions necessary to handle our use-cases, and use that for our > markup-heavy format? Additional benefit: the element could then be > included directly in the page as well, as a transcript. I think throwing timed elements directly into HTML is a bad idea. A HTML page has no notion of time and neither should have. What timeline do you synchronise a timed element with? What if there are several media elements on the page? What if there are no media elements on the page? Do we introduce a timeline for the Web page? I prefer sticking with the external approach. RSS feeds are also never made part of a Web page - only a parsed version thereof. The same should be the case with time-aligned text formats. Cheers, Silvia.
Re: [whatwg] Introduction of media accessibility features
On Wed, Apr 14, 2010 at 5:59 PM, Silvia Pfeiffer wrote: > On Thu, Apr 15, 2010 at 3:19 AM, Tab Atkins Jr. wrote: >> On Tue, Apr 13, 2010 at 11:33 PM, Silvia Pfeiffer >> wrote: >>> On Wed, Apr 14, 2010 at 1:28 PM, Robert O'Callahan >>> wrote: On Mon, Apr 12, 2010 at 12:47 PM, Silvia Pfeiffer wrote: > > Understood. But what is actually the cost of implementing all of TTML? > The features in TTML all map onto existing Web technology, so all it > takes is a bit more parsing code over time. When implementing one complex spec (TTML + XSL-FO) in terms of another complex spec (HTML + CSS), you have to be very very lucky to find that all the features map perfectly, even if the specs were designed to work together that way, which in this case they are not. Even if you're lucky today, evolution of the specs could easily accidentally break things. >>> >>> I believe it is possible today, but of course cannot prove it right >>> now. Also, future evolution of TTML will be directed by the Web in the >>> future if it gets integrated, as it would be its main use. Also: it's >>> a W3C standard, so probably would have the requirement not to break >>> the Web. So, I don't buy that latter argument. But I guess until there >>> is a mapping for all of DFXP, there probably aren't enough facts to >>> support/reject DFXP. >> >> I'd rather not be in charge of keeping them aligned perfectly. I'd >> also never want to be put in a situation where someone objects to a >> useful change in CSS because it doesn't work for TTML. Just >> integrating CSS and SVG is a pain, and there's measurable *benefit* >> there. > > If TTML creates specs that cannot be mapped, then those are ignored. > All we are basically committing to would be that a best effort is done > on the mapping. Just like with SRT we would do a best effort on the > mapping - there are SRT files now that have more than just plain text > in them. But we would not commit to interpreting every special markup > that some author came up with that worked in his particular player. > > I think the dependencies between external timed text formats and HTML5 > are much less than e.g. the dependency on SVG. TTML is not supposed to > be a native Web format in my eyes. It is just interpreted for the Web. I'm not sure I understand what you mean by "TTML is not supposed to be a native Web format"? Once browsers add support for it, it becomes a native web format. No matter if the implementation behind the scenes map xsl:fo to CSS or through some other means. Netscape 4 implemented CSS by mapping it to JSSS [1], however for all any web developer ever knew, Netscape 4 supported CSS. Poorly. I really do hate to come up with a new format. But I think TTML is severely off the mark for what we want. Am I wrong in that marking up dialogue vs. sound effects vs. narrator vs. descriptions is important? Or at least more useful than for example the ability to set the text outline blur radius? I agree with Philips email on many points, so I'll reply there instead of bringing up more details here. [1] http://en.wikipedia.org/wiki/JavaScript_Style_Sheets / Jonas
Re: [whatwg] Introduction of media accessibility features
On Thu, 15 Apr 2010 10:24:27 +0800, Tab Atkins Jr.
wrote:
On Wed, Apr 14, 2010 at 5:59 PM, Silvia Pfeiffer
wrote:
If TTML creates specs that cannot be mapped, then those are ignored.
All we are basically committing to would be that a best effort is done
on the mapping. Just like with SRT we would do a best effort on the
mapping - there are SRT files now that have more than just plain text
in them. But we would not commit to interpreting every special markup
that some author came up with that worked in his particular player.
I think the dependencies between external timed text formats and HTML5
are much less than e.g. the dependency on SVG. TTML is not supposed to
be a native Web format in my eyes. It is just interpreted for the Web.
"Best effort" mapping won't be enough as soon as this gets really
picks up. Authors can be crazy about the placement of things. We'll
end up having to define the exact mapping, or else have compat bugs on
all the browsers.
A spec would need to be written for this new extended SRT format.
Also, if we are introducing HTML markup inside SRT time cues, then it
would make sense to turn the complete SRT file into markup, not just
the part inside the time cue. Further, SRT has no way to specify which
language it is written in and further such general mechanisms that
already exist for HTML.
I don't think SRT is the right base format to start extending from.
That extension doesn't give us anything anyway, since no existing SRT
application would be able to do much with it. It is not hard to
replicate the SRT functionality in something new. If we really want to
do "SRT + HTML + CSS", then we should start completely from a blank
page.
I'm sympathetic to this sentiment. SRT seems to be the simplest
widespread format that would "just work", so extending it for the
other cases just feels like a potential win. But it might not be,
sure.
Random brainstorm: we already had an element meant to mark up
dialogues, . Perhaps we can revive it, give it the minimal
extensions necessary to handle our use-cases, and use that for our
markup-heavy format? Additional benefit: the element could then be
included directly in the page as well, as a transcript.
~TJ
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), apply document-wide styling, reference
external style sheets, use webfonts, etc...
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.
No matter the syntax, the idea is basically to allow marking up certain
parts of HTML as being relevant for certain time ranges. A CSS
pseudo-selector matches the elements which are currently active, based on
the current time of the media.
So, the external subtitle file could simply be HTML, with acting
much like an iframe with the only difference that the current time of the
document is given by the embedding or . Something like this:
...
Hello
The End
...
The default stylesheet would be something like this:
:before-timerange, :after-timerange {
display: none;
}
:in-timerange {
display: block;
}
The styling issue is trivially solved, anything you can normally do is
possible here too.
Pros:
+ Styling using CSS and only CSS.
+ Well known format to web authors and tools.
+ High reuse of existing implementations.
+ You could author CSS to make the HTML document read as a transcript
when opened directly.
+ reusable for page-embedded timed markup, which was the
original idea.
Cons:
- Politics.
- New format for subtitle authors and tools.
- Not usable outside the web platform (i.e. outside of web browsers).
- is a bit verbose, but that can be changed to whatever we
want.
Thoughts?
--
Philip Jägenstedt
Core Developer
Opera Software
Re: [whatwg] Introduction of media accessibility features
On Wed, Apr 14, 2010 at 5:59 PM, Silvia Pfeiffer wrote: > If TTML creates specs that cannot be mapped, then those are ignored. > All we are basically committing to would be that a best effort is done > on the mapping. Just like with SRT we would do a best effort on the > mapping - there are SRT files now that have more than just plain text > in them. But we would not commit to interpreting every special markup > that some author came up with that worked in his particular player. > > I think the dependencies between external timed text formats and HTML5 > are much less than e.g. the dependency on SVG. TTML is not supposed to > be a native Web format in my eyes. It is just interpreted for the Web. "Best effort" mapping won't be enough as soon as this gets really picks up. Authors can be crazy about the placement of things. We'll end up having to define the exact mapping, or else have compat bugs on all the browsers. > A spec would need to be written for this new extended SRT format. > Also, if we are introducing HTML markup inside SRT time cues, then it > would make sense to turn the complete SRT file into markup, not just > the part inside the time cue. Further, SRT has no way to specify which > language it is written in and further such general mechanisms that > already exist for HTML. > > I don't think SRT is the right base format to start extending from. > That extension doesn't give us anything anyway, since no existing SRT > application would be able to do much with it. It is not hard to > replicate the SRT functionality in something new. If we really want to > do "SRT + HTML + CSS", then we should start completely from a blank > page. I'm sympathetic to this sentiment. SRT seems to be the simplest widespread format that would "just work", so extending it for the other cases just feels like a potential win. But it might not be, sure. Random brainstorm: we already had an element meant to mark up dialogues, . Perhaps we can revive it, give it the minimal extensions necessary to handle our use-cases, and use that for our markup-heavy format? Additional benefit: the element could then be included directly in the page as well, as a transcript. ~TJ
[whatwg] Simon's WebSocket feedback
On Thu, 1 Apr 2010, Simon Pieters wrote: > > The establish a WebSocket connection algorithm says: > > [[ > 35. ... > > ↪If the byte is 0x20 (ASCII space) > Ignore the byte and move on to the next step. > > Otherwise > Treat the byte as described by the list in the next step, then move on to that > next step for real. > > Note: This skips past a space character after the colon, if necessary. > > 36. Read a byte from the server. > > If the connection closes before this byte is received, then fail the WebSocket > connection and abort these steps. > > Otherwise, handle the byte as described in the appropriate entry below: > > ↪If the byte is 0x0D (ASCII CR) > Move on to the next step. > ]] > > Consider the case when the server gives a colon followed by CR. My reading is > that step 36 will be run twice: > > Upon receiving the CR in step 35, "Treat the byte as described by the list in > the next step" which is "Move on to the next step." (i.e. step 37), "then move > on to that next step for real." (i.e. step 36). Yeah that's very confusing. Fixed. > Step 41 says: > > [[ > If the entry's name is "set-cookie" or "set-cookie2" or another cookie-related > field name > > If the relevant specification is supported by the user agent, handle the > cookie as defined by the appropriate specification, with the resource being > the one with the host host, the port port, the path (and possibly query > parameters) resource name, and the scheme http if secure is false and https if > secure is true. [COOKIES] > ]] > > What should be done if the relevant specification is not supported? Nothing. On Wed, 7 Apr 2010, Simon Pieters wrote: > > WebSocket constructor says: > > [[ > 2. If port is a port to which the user agent is configured to block access, > then throw a SECURITY_ERR exception. (User agents typically block access to > well-known ports like SMTP.) > ]] > > Should port 80 be blocked for wss:? Should port 443 be blocked for ws:? > Please state explicitly. Done. On Thu, 8 Apr 2010, Simon Pieters wrote: > > WebSockets constructor: > > [[ > 4. Let origin be the ASCII serialization of the origin of the script that > invoked the WebSocket() constructor, converted to ASCII lowercase. > ... > 6. Establish a WebSocket connection... > ]] > > which says > > [[ > 13. Add the string consisting of the concatenation of the string "Origin:", a > U+0020 SPACE character, and the origin value, converted to ASCII lowercase, to > fields. > ... > 41. ... > If the entry's name is "sec-websocket-origin" > If the value is not exactly equal to origin, converted to ASCII lowercase, > then fail the WebSocket connection and abort these steps. [ORIGIN] > ]] > > Isn't it enough to convert it to lowercase once, in the constructor? Fixed. > Sending the server's opening handshake says > > [[ > origin > The ASCII serialization of the origin that the server is willing to > communicate with. If the server can respond to requests from multiple origins > (or indeed, all origins), then the value should be derived from the client's > handshake, specifically from the "Origin" field. [ORIGIN] > ]] > > Shouldn't the server convert the origin to lowercase if that's the format the > client expects? Or should the client accept case-insensitive origin instead? Good point. Fixed. On Fri, 9 Apr 2010, Simon Pieters wrote: > > WebSocket send() says: > > [[ > The send(data) method transmits data using the connection. If the readyState > attribute is CONNECTING, it must raise an INVALID_STATE_ERR exception. If the > data argument has any unpaired surrogates, then it must raise SYNTAX_ERR. > ]] > > If readyState is CONNECTING *and* the data argument has unpaired > surrogates, then my literal reading suggests two exceptions should be > raised. I assume this is not correct and the spec should include an > "Otherwise,". Fixed. On Mon, 12 Apr 2010, Simon Pieters wrote: > > WebSocket establish a WebSocket connection: > > [[ > 21. Insert spaces1 U+0020 SPACE characters into key1 at random positions. > > Insert spaces2 U+0020 SPACE characters into key2 at random positions. > ]] > > It seems a bit risky to insert spaces at the start and at the end of the > string; I imagine some servers would ignore them (which would be a bug > in the server, but hard to notice since it's random). Maybe we should > avoid inserting them at the start and at the end. Since key1 and key2 can be numbers in the range 1-9, I don't see how to avoid at least one of those two places. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Introduction of media accessibility features
On Thu, Apr 15, 2010 at 3:19 AM, Tab Atkins Jr. wrote: > On Tue, Apr 13, 2010 at 11:33 PM, Silvia Pfeiffer > wrote: >> On Wed, Apr 14, 2010 at 1:28 PM, Robert O'Callahan >> wrote: >>> On Mon, Apr 12, 2010 at 12:47 PM, Silvia Pfeiffer >>> wrote: Understood. But what is actually the cost of implementing all of TTML? The features in TTML all map onto existing Web technology, so all it takes is a bit more parsing code over time. >>> >>> When implementing one complex spec (TTML + XSL-FO) in terms of another >>> complex spec (HTML + CSS), you have to be very very lucky to find that all >>> the features map perfectly, even if the specs were designed to work together >>> that way, which in this case they are not. Even if you're lucky today, >>> evolution of the specs could easily accidentally break things. >> >> I believe it is possible today, but of course cannot prove it right >> now. Also, future evolution of TTML will be directed by the Web in the >> future if it gets integrated, as it would be its main use. Also: it's >> a W3C standard, so probably would have the requirement not to break >> the Web. So, I don't buy that latter argument. But I guess until there >> is a mapping for all of DFXP, there probably aren't enough facts to >> support/reject DFXP. > > I'd rather not be in charge of keeping them aligned perfectly. I'd > also never want to be put in a situation where someone objects to a > useful change in CSS because it doesn't work for TTML. Just > integrating CSS and SVG is a pain, and there's measurable *benefit* > there. If TTML creates specs that cannot be mapped, then those are ignored. All we are basically committing to would be that a best effort is done on the mapping. Just like with SRT we would do a best effort on the mapping - there are SRT files now that have more than just plain text in them. But we would not commit to interpreting every special markup that some author came up with that worked in his particular player. I think the dependencies between external timed text formats and HTML5 are much less than e.g. the dependency on SVG. TTML is not supposed to be a native Web format in my eyes. It is just interpreted for the Web. >>> We could make that problem go away by normatively defining something that >>> looks like TTML in terms of a translation to HTML + CSS. It wouldn't really >>> be TTML though, and where's the added value for authors? >>> >>> I understand the deep political problems here, but I think it's most logical >>> for styled content for the Web to use (possibly a subset of) HTML and CSS. >>> Server-side tools to translate between TTML and HTML+CSS would be one way to >>> address the desire to interoperate with TTML. >> >> I personally have no issue with introducing a new format - even >> experimented with one some time ago, see >> http://wiki.xiph.org/Timed_Divs_HTML . There are challenges with this, >> too, and they are not only political. For example, I think we would >> need to restrict some things from appearing in timed sections: e.g. >> would we really want to allow multiple layers of video rendered on top >> of video? But we could develop a new format - just like we have >> developed microdata. >> >> Introducing a new format would indeed be mainly a political problem. >> Not just would it go "against" all other existing formats. It would >> also be a challenge to get other applications to support it, in >> particular applications that do not contain a Web framework. >> >> Thus, my thinking was that what we do internally is basically HTML+CSS >> on time sections. And all formats that we read from externally will be >> mapped to that. We would already do that with SRT, too. > > +1 to Henry's suggestion of just using two formats: SRT, and SRT + > (possibly some subset of) HTML+CSS, where the latter is simply a > normal SRT file with HTML allowed where it would normally only allow > plaintext for the caption. > > That seems to be the minimal change that can address this case, and > appears to be a fairly logical extension of an existing widespread > format. A spec would need to be written for this new extended SRT format. Also, if we are introducing HTML markup inside SRT time cues, then it would make sense to turn the complete SRT file into markup, not just the part inside the time cue. Further, SRT has no way to specify which language it is written in and further such general mechanisms that already exist for HTML. I don't think SRT is the right base format to start extending from. That extension doesn't give us anything anyway, since no existing SRT application would be able to do much with it. It is not hard to replicate the SRT functionality in something new. If we really want to do "SRT + HTML + CSS", then we should start completely from a blank page. Cheers, Silvia.
Re: [whatwg] Proposal for secure key-value data stores
Yes, |localStorage.setItem(AES.encrypt("username", key),
AES.encrypt("Nicholas", key));| is a bit ugly, but many things in the web
platform are. And honestly, it's not _that_ ugly or _that_ many extra
characters. And this is the type of problem JS libraries often solve.
I'd suggest you talk to various libraries (or write your own) about adding
a compatibility layer that includes JS crypto and in parallel talk to
browser vendors about adding a crypto API.
Anyhow, I can say with a fairly high level of certainty that we (Chromium)
are not interested in implementing this. But maybe others (Mozilla?) are.
So I'm going to withdraw myself from this discussion since I don't seem to
be adding any new information to it and I think everyone knows where I
stand. :-)
J
On Wed, Apr 14, 2010 at 5:23 PM, Nicholas Zakas wrote:
> I tried to articulate some of my thoughts as to why a generate purpose
> crypto isn’t enough to be useful and why trying to tack onto local storage
> could get messy:
>
>
> http://www.nczonline.net/blog/2010/04/13/towards-more-secure-client-side-data-storage/
>
>
>
>
>
> -Nicholas
>
>
>
> __
>
> Commander Lock: "Damnit Morpheus, not everyone believes what you believe!"
>
> Morpheus: "My beliefs do not require them to."
> --
>
> *From:* whatwg-boun...@lists.whatwg.org [mailto:
> whatwg-boun...@lists.whatwg.org] *On Behalf Of *Jeremy Orlow
> *Sent:* Thursday, April 08, 2010 3:14 AM
> *To:* Jonas Sicking
> *Cc:* whatwg@lists.whatwg.org; Dirk Pranke; Nicholas Zakas; Eric Uhrhane
>
> *Subject:* Re: [whatwg] Proposal for secure key-value data stores
>
>
>
> On Thu, Apr 8, 2010 at 2:10 AM, Jonas Sicking wrote:
>
> On Wed, Apr 7, 2010 at 5:44 PM, Jeremy Orlow wrote:
> >> I don't think this is enough of a
> >> problem to kill the feature though.
> >
> > I think this is a good feature to try and integrate into existing APIs if
> > it's possible to do so cleanly. I don't think it's worth creating yet
> > another persistent storage API over, though.
>
> ...
>
> > For
> > localStorage, we could add a origin-wide setting or add an optional param
> to
> > setItem.
>
> Well, it seems harsh to require that *all* data on a domain is either
> security sensitive, and thus need expiration, or not security
> sensitive and thus need none. I think it makes a lot of sense to be
> able to let the page have several storage areas, some which expire and
> some which don't.
>
> Think mail.google.com where storing my emails would count as sensitive
> and should have expiration, but storing my drafts might be worth doing
> longer to prevent dataloss.
>
>
>
> Local storage is not a good API for more complex applications like gmail.
> That's why I suggested integrating into IndexedDB and WebSQLDatabase (which
> is what I meant when I said "databases"). Note that I also suggested that
> it could be an optional parameter to setItem which would make it a per-item
> setting and still be backwards compatible with LocalStorage. (Like I said,
> creating another LocalStorage-like API just for this feature is really not
> an option.)
>
>
>
> I just thought of an alternative approach to this whole situation
> though. We could add crypto and expiration functionality to IndexDB. I
> know the crypto stuff has come up before and there was some hesitation
> though. (Though I guess the same thing could be said for
> crypto+localStorage)
>
>
>
> Nikunj has already said no more major features for v1 of IndexedDB. I
> think we might be able to sneak in an expiration parameter, but encryption
> 1) is not practical for v1 and 2) we're really jumping the gun on this
> encryption thing. One person proposed it. We haven't seen any evidence
> this is a widely sought after feature. If _anything_ the right way to go is
> to make encryption fast and allow developers and authors of libraries to
> layer the two. If there's compelling demand, THEN we should talk about
> adding it to individual APIs.
>
>
>
> > It seems as though expiration policies could be added to the creation
> of
> > databases and the new FileWriter/FileSystem APIs pretty easily.
>
> I don't understand the usecase of expiring files. Isn't the whole
> point of saving to the file system so that the user gets better access
> to it and so that things like iPhoto can index any stored images?
>
>
> > But stillwe need some use cases. :-)
>
> I'm all for use cases. Though Nicholas did say that he'd want
> encryption and expiration on essentially all privacy sensitive
> information stored. Which I think I can understand.
>
>
>
> As stated, a more general purpose crypto API should be enough to satisfy
> this use case and others (like someone wanting to encrypt it client side
> before sending it to the server). That is the direction these discussions
> should be headed, not taking one particular persistent storage API
> and finding a way to tack encryption onto it.
>
Re: [whatwg] Proposal for secure key-value data stores
I tried to articulate some of my thoughts as to why a generate purpose crypto isn't enough to be useful and why trying to tack onto local storage could get messy: http://www.nczonline.net/blog/2010/04/13/towards-more-secure-client-side -data-storage/ -Nicholas __ Commander Lock: "Damnit Morpheus, not everyone believes what you believe!" Morpheus: "My beliefs do not require them to." From: whatwg-boun...@lists.whatwg.org [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Jeremy Orlow Sent: Thursday, April 08, 2010 3:14 AM To: Jonas Sicking Cc: whatwg@lists.whatwg.org; Dirk Pranke; Nicholas Zakas; Eric Uhrhane Subject: Re: [whatwg] Proposal for secure key-value data stores On Thu, Apr 8, 2010 at 2:10 AM, Jonas Sicking wrote: On Wed, Apr 7, 2010 at 5:44 PM, Jeremy Orlow wrote: >> I don't think this is enough of a >> problem to kill the feature though. > > I think this is a good feature to try and integrate into existing APIs if > it's possible to do so cleanly. I don't think it's worth creating yet > another persistent storage API over, though. ... > For > localStorage, we could add a origin-wide setting or add an optional param to > setItem. Well, it seems harsh to require that *all* data on a domain is either security sensitive, and thus need expiration, or not security sensitive and thus need none. I think it makes a lot of sense to be able to let the page have several storage areas, some which expire and some which don't. Think mail.google.com where storing my emails would count as sensitive and should have expiration, but storing my drafts might be worth doing longer to prevent dataloss. Local storage is not a good API for more complex applications like gmail. That's why I suggested integrating into IndexedDB and WebSQLDatabase (which is what I meant when I said "databases"). Note that I also suggested that it could be an optional parameter to setItem which would make it a per-item setting and still be backwards compatible with LocalStorage. (Like I said, creating another LocalStorage-like API just for this feature is really not an option.) I just thought of an alternative approach to this whole situation though. We could add crypto and expiration functionality to IndexDB. I know the crypto stuff has come up before and there was some hesitation though. (Though I guess the same thing could be said for crypto+localStorage) Nikunj has already said no more major features for v1 of IndexedDB. I think we might be able to sneak in an expiration parameter, but encryption 1) is not practical for v1 and 2) we're really jumping the gun on this encryption thing. One person proposed it. We haven't seen any evidence this is a widely sought after feature. If _anything_ the right way to go is to make encryption fast and allow developers and authors of libraries to layer the two. If there's compelling demand, THEN we should talk about adding it to individual APIs. > It seems as though expiration policies could be added to the creation of > databases and the new FileWriter/FileSystem APIs pretty easily. I don't understand the usecase of expiring files. Isn't the whole point of saving to the file system so that the user gets better access to it and so that things like iPhoto can index any stored images? > But stillwe need some use cases. :-) I'm all for use cases. Though Nicholas did say that he'd want encryption and expiration on essentially all privacy sensitive information stored. Which I think I can understand. As stated, a more general purpose crypto API should be enough to satisfy this use case and others (like someone wanting to encrypt it client side before sending it to the server). That is the direction these discussions should be headed, not taking one particular persistent storage API and finding a way to tack encryption onto it.
[whatwg] WebSocket.bufferedAmount
The changes discussed below are summarised in this diff: http://html5.org/tools/web-apps-tracker?from=5048&to=5049 On Thu, 25 Mar 2010, Olli Pettay wrote: > > IMO scripts should be able to check whether the data they have posted is > actually sent over the network. That requirement is handled by basically any solution that eventually drops to zero, provided you mean local send, and is only handled by a remote ack, if you mean sent all the way over the network to the other end. On Thu, 25 Mar 2010, Anne van Kesteren wrote: > > I think what also matters here is how the protocol will evolve. Is it > that expectation that send(DOMString) can eventually send very different > things over the wire depending on how the server reacts to the initial > handshake request? How do the various options we have evaluate against > the potential scenarios coming out of that? Yeah, if we add opt-in compression then the number of bytes sent including overhead could be smaller than the number of bytes in UTF-8 excluding overhead. It doesn't seem to much matter what exactly the number we use is so long as it is consistent across UAs. On Fri, 26 Mar 2010, Olli Pettay wrote: > > And if bufferedAmount includes the overhead, it needs to be specified > what bufferedAmount is during handshake. I've clarified that the handshake doesn't affect it. On Fri, 26 Mar 2010, Boris Zbarsky wrote: > On 3/25/10 5:50 PM, Ian Hickson wrote: > > What would the use case be for the second one? As far as I'm aware > > there's only one use case here: making it possible to saturate the > > network but not over-saturate it (i.e. to send data at the exact rate > > that the network can take it, without getting behind by sending more > > data than the network can handle, and without sending so little that > > the network is ever idle). > > In practice, with real networks whose speed varies second-to-second, > this is not really feasible. You can do a reasonable job, but I agree that perfection is impossible. The more latency you're willing to put up with, the better a job you can do, up to a limit. > And given the various levels of buffering in a typical network stack, > I'm not quite sure how you see this working from the JS app's point of > view. Or is bufferedAmount reporting the amount of data that the server > has not yet acknowledged receipt of or something? The draft I'm looking > at doesn't say anything like that, but maybe it's out of date? This is only the amount the UA hasn't sent, network stack buffering is not affected here. Effectively if this number is not zero, most of the other buffers are going to be full already. It's probably wise to try to keep this number as low as possible if you want good latency. > That's not even worrying about issues like the network becoming "idle" > while you're waiting for your process's time slice or whatnot. Indeed, nothing we can do here really helps with the case of the UA not being able to fill the network fast enough to saturate it. > > I don't see a problem with defining this. I agree that if we include > > overhead that it should be defined, but just saying that it's "the > > number of bytes to be sent that have not yet been sent to the network" > > does define it, as far as I can tell. > > I'm still not quite sure why the "number of bytes" would include the > websocket framing bytes but not the SSL bytes, the IP bytes, the > ethernet frame, the Tor stuff when that's in use, etc. What makes them > special in terms of the protocol consumer needing to know about them (I > realize they're special in that we're defining the web socket protocol)? > This isn't a rhetorical question, to be clear; I genuinely don't see a > difference That's a fair point. > > I think viewing the API spec and the protocol spec as separate is a > > mistake. They are one document: > > Hold on. There doesn't have to be a tight coupling between API and > protocol here, as far as I can see. The API just deals with messages. > It seems pretty protocol-agnostic to me (and in particular, it seems to > me like the protocol can evolve without changing the API). > > Is there a good reason to actually couple them? They're one feature. Why would we not couple them? If we decouple them it's much more likely that they'll evolve in suboptimal ways. > Given that, do we in fact need byte-exact values here at all? For > example, could we make reporting it whichever way conforming as long as > it satisfies certain criteria (monotonicity, etc)? > > This is one of those cases (and I don't say this often!) when I actually > happen to think that overspecifying (in either direction) precludes or > over-complicates some perfectly valid and reasonable implementation > strategies, and since in practice the values returned don't matter much > I'd prefer to not thus overspecify. I'm a little concerned that if one browser returns numbers that are a factor of 2 diff
[whatwg] confusion between article and summary; editorial change suggestion
The definition for article says "The article element represents a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g. in syndication." This suggests that if you have a self-contained composition that you do not intend to be distributable via syndication, you shouldn't use . Section says "Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the element" - here, the intent of syndication is diluted into "it would make sense to syndicate the content". I suggest that article be amended to say something similar, eg "The article element represents a self-contained composition in a document, page, application, or site which would make sense if independently distributed or reused, e.g. in syndication." so that the two mentions of match, especially given that Jeremy Keith has reported confusion between article and summary. -- Hang loose and stay groovy, Bruce Lawson Web Evangelist www.opera.com (work) www.brucelawson.co.uk (personal) www.twitter.com/brucel
Re: [whatwg] Introduction of media accessibility features
On Wed, Apr 14, 2010 at 10:19 AM, Tab Atkins Jr. wrote:
> On Tue, Apr 13, 2010 at 11:33 PM, Silvia Pfeiffer
> wrote:
>> On Wed, Apr 14, 2010 at 1:28 PM, Robert O'Callahan
>> wrote:
>>> On Mon, Apr 12, 2010 at 12:47 PM, Silvia Pfeiffer
>>> wrote:
Understood. But what is actually the cost of implementing all of TTML?
The features in TTML all map onto existing Web technology, so all it
takes is a bit more parsing code over time.
>>>
>>> When implementing one complex spec (TTML + XSL-FO) in terms of another
>>> complex spec (HTML + CSS), you have to be very very lucky to find that all
>>> the features map perfectly, even if the specs were designed to work together
>>> that way, which in this case they are not. Even if you're lucky today,
>>> evolution of the specs could easily accidentally break things.
>>
>> I believe it is possible today, but of course cannot prove it right
>> now. Also, future evolution of TTML will be directed by the Web in the
>> future if it gets integrated, as it would be its main use. Also: it's
>> a W3C standard, so probably would have the requirement not to break
>> the Web. So, I don't buy that latter argument. But I guess until there
>> is a mapping for all of DFXP, there probably aren't enough facts to
>> support/reject DFXP.
>
> I'd rather not be in charge of keeping them aligned perfectly. I'd
> also never want to be put in a situation where someone objects to a
> useful change in CSS because it doesn't work for TTML. Just
> integrating CSS and SVG is a pain, and there's measurable *benefit*
> there.
W3C has a long history of creating incompatible specs, so I would not
rely on them to "not break the web". Just look at all the
incompatibilities between SVG and CSS (unitless lengths for example),
SVG and DOM ('evt' vs 'event'). And this is still going on (XHTML WG
reusing both the 'text/html' mimetype and the XHTML 1.1 namespace for
an incompatible XHTML2 language).
I would be very surprised if XSL:FO is compatible with CSS. I think
there was little to no cooperation between the two efforts.
>>> We could make that problem go away by normatively defining something that
>>> looks like TTML in terms of a translation to HTML + CSS. It wouldn't really
>>> be TTML though, and where's the added value for authors?
>>>
>>> I understand the deep political problems here, but I think it's most logical
>>> for styled content for the Web to use (possibly a subset of) HTML and CSS.
>>> Server-side tools to translate between TTML and HTML+CSS would be one way to
>>> address the desire to interoperate with TTML.
>>
>> I personally have no issue with introducing a new format - even
>> experimented with one some time ago, see
>> http://wiki.xiph.org/Timed_Divs_HTML . There are challenges with this,
>> too, and they are not only political. For example, I think we would
>> need to restrict some things from appearing in timed sections: e.g.
>> would we really want to allow multiple layers of video rendered on top
>> of video? But we could develop a new format - just like we have
>> developed microdata.
>>
>> Introducing a new format would indeed be mainly a political problem.
>> Not just would it go "against" all other existing formats. It would
>> also be a challenge to get other applications to support it, in
>> particular applications that do not contain a Web framework.
>>
>> Thus, my thinking was that what we do internally is basically HTML+CSS
>> on time sections. And all formats that we read from externally will be
>> mapped to that. We would already do that with SRT, too.
>
> +1 to Henry's suggestion of just using two formats: SRT, and SRT +
> (possibly some subset of) HTML+CSS, where the latter is simply a
> normal SRT file with HTML allowed where it would normally only allow
> plaintext for the caption.
>
> That seems to be the minimal change that can address this case, and
> appears to be a fairly logical extension of an existing widespread
> format.
I like this approach, though I wonder how it's intended to attach a
stylesheet to the SRT+HTML file?
An alternative approach is to simply use HTML+microdata. I.e. take an
HTML file, and add microdata to describe which element should be
displayed when.
Of course, even better would be to have a markup language for marking
up the meaning of the timed text. For example, it's unfortunate that
the DFXP markup contains things like
[Water dropping]
[plop, plop, plop, …]
Where the brackets clearly mean that the contained text isn't being
said, but that they are sound effects. This would be much better done
with markup like:
Water dropping
plop, plop, plop
It strikes me as interesting that DFXP is as complicated as it is,
without solving, what at least I perceive as, this very basic need.
On a separate note, I note that the DFXP file seems to be specific to
a specific size of the video. If I resize the video, the captions that
go on top of the video doesn't move appropriately. This could very
well simply be due to th
Re: [whatwg] Introduction of media accessibility features
On Tue, Apr 13, 2010 at 11:33 PM, Silvia Pfeiffer wrote: > On Wed, Apr 14, 2010 at 1:28 PM, Robert O'Callahan > wrote: >> On Mon, Apr 12, 2010 at 12:47 PM, Silvia Pfeiffer >> wrote: >>> >>> Understood. But what is actually the cost of implementing all of TTML? >>> The features in TTML all map onto existing Web technology, so all it >>> takes is a bit more parsing code over time. >> >> When implementing one complex spec (TTML + XSL-FO) in terms of another >> complex spec (HTML + CSS), you have to be very very lucky to find that all >> the features map perfectly, even if the specs were designed to work together >> that way, which in this case they are not. Even if you're lucky today, >> evolution of the specs could easily accidentally break things. > > I believe it is possible today, but of course cannot prove it right > now. Also, future evolution of TTML will be directed by the Web in the > future if it gets integrated, as it would be its main use. Also: it's > a W3C standard, so probably would have the requirement not to break > the Web. So, I don't buy that latter argument. But I guess until there > is a mapping for all of DFXP, there probably aren't enough facts to > support/reject DFXP. I'd rather not be in charge of keeping them aligned perfectly. I'd also never want to be put in a situation where someone objects to a useful change in CSS because it doesn't work for TTML. Just integrating CSS and SVG is a pain, and there's measurable *benefit* there. >> We could make that problem go away by normatively defining something that >> looks like TTML in terms of a translation to HTML + CSS. It wouldn't really >> be TTML though, and where's the added value for authors? >> >> I understand the deep political problems here, but I think it's most logical >> for styled content for the Web to use (possibly a subset of) HTML and CSS. >> Server-side tools to translate between TTML and HTML+CSS would be one way to >> address the desire to interoperate with TTML. > > I personally have no issue with introducing a new format - even > experimented with one some time ago, see > http://wiki.xiph.org/Timed_Divs_HTML . There are challenges with this, > too, and they are not only political. For example, I think we would > need to restrict some things from appearing in timed sections: e.g. > would we really want to allow multiple layers of video rendered on top > of video? But we could develop a new format - just like we have > developed microdata. > > Introducing a new format would indeed be mainly a political problem. > Not just would it go "against" all other existing formats. It would > also be a challenge to get other applications to support it, in > particular applications that do not contain a Web framework. > > Thus, my thinking was that what we do internally is basically HTML+CSS > on time sections. And all formats that we read from externally will be > mapped to that. We would already do that with SRT, too. +1 to Henry's suggestion of just using two formats: SRT, and SRT + (possibly some subset of) HTML+CSS, where the latter is simply a normal SRT file with HTML allowed where it would normally only allow plaintext for the caption. That seems to be the minimal change that can address this case, and appears to be a fairly logical extension of an existing widespread format. ~TJ
