[whatwg] XMLHttpRequest and HTML5
Ian, if you could tackle the following soonish that would be nice as I try to get the test suite for XMLHttpRequest together. 1) document.location returns null when there is no browsing context for the Document. document.defaultView needs this too. (It returns null in the implementations I tested.) 2) Is there any reason we cannot also use this no browsing context clause to define document.cookie rather than having a special type of Document object? Seems much better. 3) And document.domain too, maybe? (There is a difference here currently which is that document.domain just special cases XMLHttpRequest whereas the cookie-free Document object concept also applies to createDocument(). I suspect document.domain should have the same restrictions, but I am not sure. It would be nice however if document.domain did not have to reference XMLHttpRequest.) 4) I could not test Internet Explorer but so far only WebKit exposes document.domain in XMLHttpRequest and it does not throw on getting and on setting it throws a SECURITY_ERR (not INVALID_STATE_ERR). If we align with document.cookie as suggested above maybe this should align too and getting should return the empty string and setting should be ignored. 5) I think we want to ban document.lastModified too. At least for cross-origin requests and the way we did it elsewhere was to then ban it for same-origin as well. (The HTTP header can be read instead. It also does not seem like a huge loss.) 6) If you provide some hook or tell me how to do it I can define the origin of the Document returned by responseXML in XMLHttpRequest. If we can do all this that should turn it into a one-way dependency with most definitions being completely self-contained. Thanks, -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Discussing WebSRT and alternatives/improvements
On Sat, Aug 7, 2010 at 1:50 AM, Philip Jägenstedt phil...@opera.com wrote: Snipping liberally... On Thu, 05 Aug 2010 17:01:47 +0200, Silvia Pfeiffer silviapfeiff...@gmail.com wrote: CONSIDERING EXISTING FORMATS Note that the subtitling community has traditionally been using the Subrip (srt) or SubViewer (sub) formats as a simple format and SubStation alpha (ssa/ass) as the comprehensive format. Aegisub, the successor of SubStation Alpha, is still the most popular subtitling software and ASS is the currently dominant format. However, even this community is right now developing a new format called AS6. This shows that the subtitling community also hasn't really converged on a best format yet. Maybe it's just me, but I've very rarely seen ASS in the wild. In fact, almost all fansubbed videos I've seen were hardsubbed (subtitles encoded as part of the video), presumably because the subbers thought their choice of font and colors was really important. Perhaps they were still using ASS or similar to author the subtitles, I don't know. (In my own limited fansubbing efforts, SRT was quite sufficient.) Actually, many of the subtitles on http://www.opensubtitles.org/ are in .ssa format. It's not dominant next to .sub and .srt, but it's the one more complex format that is used and very actively supported in Matroska. Cheers, Silvia.
[whatwg] Fwd: Discussing WebSRT and alternatives/improvements
Hi Philip,
On Sat, Aug 7, 2010 at 1:50 AM, Philip Jägenstedt phil...@opera.com wrote:
If @profile should have any influence on the parser it sounds like this
isn't actually XML at all. In particular, the HTML would have to be
well-formed XML, but would still end up in the null namespace.
Yeah, you are right - I suppose I was trying to imitate the flexibility of
WebSRT there with an anything option.
I guess simply cloning the child nodes of cue and changing their
namespace to before inserting them into an iframe-like document might work,
but would be quite odd, I think you'll agree.
Yes, it's no different to WebSRT in that respect.
* there is a possibility to provide script that just affects the
time-synchronized text resource
I agree that some metadata would be useful, more on that below. I'm not
sure why we would want to run scripts inside the text document, though, when
that can be accomplished by using the TimedTrack API from the containing
page.
Scripts inside a timed text document would only be useful for applications
that use the track not in conjunction with a Web page.
The cue elements have a start and end time attribute and contain
innerHTML, thus there is already parsing code available in Web browsers to
deal with this content. Any Web content can be introduced into a cue and
the Web browsers will already be able to render it.
Yes, but if the HTML parser can't be used for all of WMML, it makes the
parser quite odd, being neither XML or HTML. I think that realistically the
best way to make an XML-like format is to simply use XML.
OK. Then everything that's not supposed to be parsed inside a cue would be
escaped. I guess that works, too.
2. There is a natural mapping of WebSRT into in-band text tracks.
Each cue naturally maps into a encoding page (just like a WMML cue does,
too). But in WebSRT, because the setup information is not brought in a
hierarchical element surrounding all cues, it is easier to just chuck
anything that comes before the first cue into an encoding header page. For
WMML, this problem can be solved, but it is less natural.
I really like the idea of letting everything before the first timestamp in
WebSRT be interpreted as the header. I'd want to use it like this:
# author: Fan Subber
# voices: 1 Boy
# 2 Girl
01:23:45.678 -- 01:23:46.789
1 Hello
01:23:48.910 -- 01:23:49.101
2 Hello
It's not critical that the format of the header be machine-readable, but we
could of course make up a key-value syntax, use JSON, or something else.
I disagree. I think it's absolutely necessary that the format of the header
be machine-readable. Just like EXIF in images is machine readable or ID3 in
MP3 is machine-readable. It would be counter-productive not to have it
machine-readable, in particular useless to archiving and media management
solutions.
I'm not sure of the best solution. I'd quite like the ability to use
arbitrary voices, e.g. to use the names/initials of the speaker rather than
a number, or to use e.g. shouting in combination with CSS :before {
content 'Shouting: ' } or similar to adapt the display for different
audiences (accessibility, basically).
I agree. I think we can go back to usingspan and @class and @id and that
would solve it all.
4. It's a light-weight format in that it is not very verbose.
It is nice for hand-authoring if you don't have to write so much. This is
particularly true for the simple case. E.g. if new-lines that you author
are
automatically kept as newlines when interpreted. The drawbacks here are
that
as soon as you include more complicated markup into the cues (e.g. HTML
markup or a SVG image), you're not allowed to put empty lines into it
because they have a special meaning. So, while it is true that the number
of
characters for WebSRT will always be less than for any markup-based
format,
this may be really annoying in any of the cases that need more than plain
text.
It would be easy to just let the parser consume all lines until the next
timestamp, but do you really want to separate two lines with a blank line?
If the two lines aren't really related, one could instead have two cues with
different vertical positioning.
In marked-up content for readability I would at least not want every newline
to impose a new display line. But I suppose since it's of kind metadata
anyway, that wouldn't happen. So, I see - it's not such a big issue.
Point 2 is possible in WMML through encoding all outer markup in a
header
and the cues in the data packets.
To be clear, this would be a new codec type for the container, since I'm
not aware of any that allow stating that the cue text is HTML. The same is
true of WebSRT, muxing it into e.g. WebM would require the ability to
express the kind from track kind=captions (although in practice such
metadata in binary files ends up almost always being incorrect).
All text tracks that are encoded
[whatwg] Please consider allowing the time element to accept coarser granularity dates
Summary: the new time element is very useful for absolute dates and times, but omits several useful granularity levels, in particular for dates. The following additional date granularities would be useful, and are fairly straightforward to incorporate into the spec (and implementations): * year only: * year-month only: -MM (also corresponds to output form of input type=month) * year-week only: -WNN (also corresponds to output form of input type=week) * month-day only: --MM-DD (common birthdays without year use case) More details, use-cases, research here: http://wiki.whatwg.org/wiki/Time#Date_granularity I encourage fellow web authors and browser implementers to add their opinions/comments to that wiki page section. Note that there are additional proposals on that page - I'm sending one email per proposal (or strongly related set of proposals) to better track them separately. Feel free to read through and comment on other proposals on the page as well. Thanks! Tantek -- http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5
Re: [whatwg] input type=ink proposal
On Fri, Aug 6, 2010 at 10:11 PM, Ian Hickson i...@hixie.ch wrote: Are there examples of sites working around the lack of this feature on the Web today, e.g. using Flash or some such? Nordic banking sites use java for authorization, that's just for pins (imo it's stupid). http://news.cnet.com/UPS-signatures-raise-concerns/2100-1023_3-277923.html comes to mind as a general concern. Note that if a browser wants to handle input type=file accept=image/svg+xml by letting the user paint using an input method, the browser is free to do that today. Similarly, a web page could actually provide its own Ink implementation and use input type=hidden to encode a signature today. If implementations spring up like mushrooms, we could revisit supporting it. Until then adding extra required file format support to web browsers seems onerous
