date:20100723

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.

Re: [whatwg] Timed tracks for video

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

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

HTH,
-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Timed tracks for video

On Thu, Jul 22, 2010 at 11:31 PM, Ian Hickson i...@hixie.ch 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

Re: [whatwg] Timed tracks for video

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] video application/octet-stream

On Thu, 22 Jul 2010 22:40:44 +0200, Maciej Stachowiak m...@apple.com  
wrote:




On Jul 22, 2010, at 3:30 AM, Philip Jägenstedt wrote:

On Thu, 22 Jul 2010 11:22:45 +0200, Henri Sivonen hsivo...@iki.fi  
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 source 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-source 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] HTMLMediaElement.preload and stalled event

On Fri, 23 Jul 2010 05:25:37 +0200, Chris Pearce ch...@pearce.org.nz  
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] Timed tracks for video

On Fri, Jul 23, 2010 at 1:00 AM, Ian Hickson i...@hixie.ch 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] Timed tracks for video


On Fri, 23 Jul 2010 07:40:57 +0200, Ian Hickson i...@hixie.ch 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 track kind=metadata, 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 itext
resource. A @default attribute has been added to the itext elements to
allow for the Web content author to tell the browser which itext
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 itext
categories on. Further, the UA is set to a default language and it is
this default language that should be used to select which itext 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 video autoplay 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 canvas, 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. img and video, but it seems to make things simpler, so I'm fine  
with that. It also ensures that JavaScript fallback handling of track  
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 canvas or just clipping divs). 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 track 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

Re: [whatwg] Timed tracks for video

2010-07-23 Thread Henri Sivonen

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 font color 
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 
!DOCTYPE html 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 timerange 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 to 
support seeking. If

[whatwg] video 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 silviapfeiff...@gmail.com
To: Philip Jägenstedt phil...@opera.com
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 phil...@opera.com
wrote:

On Thu, 22 Jul 2010 01:23:09 +0200, Silvia Pfeiffer
silviapfeiff...@gmail.com 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:

!DOCTYPE html
html lang=en
 body
   video controls width=400px
 source type=video/mp4
 source type=video/webm
 source type=video/ogg
   /video
   pcurrentSrc on start: span id=currentSrc_first/span./p
   pcurrentSrc after loadedmetadata: span
id=currentSrc_loadedmetadata/span./p
   script type=text/javascript
 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);
   /script
 /body
/html

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

Re: [whatwg] Please disallow javascript: URLs in browser address bars

2010-07-23 Thread João Eiras

On Thu, 22 Jul 2010 21:32:39 +0100, Luke Hutchison luke.hu...@mit.edu  
wrote:



[snip]

Comments, please?


This is entirely out of scope of any specification and 100% an user agent  
UI issue.

Re: [whatwg] Canvas stroke alignment

2010-07-23 Thread Nick


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] Why not creating a category for elements candidate for constraint validation?

2010-07-23 Thread Mounir Lamouri

On 07/20/2010 04:07 PM, Simon Pieters wrote:
 On Tue, 20 Jul 2010 15:47:32 +0200, Mounir Lamouri
 mounir.lamo...@gmail.com 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 textarea has .type.)

But keygen, object, fieldset and output are barred from
constraint validation and textarea, button, input and select 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, output should not be barred and button should.
But that's another topic.

Thanks,
--
Mounir

Re: [whatwg] Please disallow javascript: URLs in browser address bars

2010-07-23 Thread Ryosuke Niwa

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 jo...@opera.com wrote:

 On Thu, 22 Jul 2010 21:32:39 +0100, Luke Hutchison luke.hu...@mit.edu
 wrote:

  [snip]

 Comments, please?


 This is entirely out of scope of any specification and 100% an user agent
 UI issue.

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 i...@hixie.ch 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 time 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. `._.-(,_..'--(,_..'`-.;.'

[whatwg] [URL] Starting work on a URL spec

2010-07-23 Thread Adam Barth

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

2010-07-23 Thread Tab Atkins Jr.

On Fri, Jul 23, 2010 at 11:54 AM, Ian Hickson i...@hixie.ch 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

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] Why not creating a category for elements candidate for constraint validation?

On Fri, Jul 23, 2010 at 10:01 AM, Mounir Lamouri
mounir.lamo...@gmail.com wrote:
 On 07/20/2010 04:07 PM, Simon Pieters wrote:
 On Tue, 20 Jul 2010 15:47:32 +0200, Mounir Lamouri
 mounir.lamo...@gmail.com 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 textarea has .type.)

 But keygen, object, fieldset and output are barred from
 constraint validation and textarea, button, input and select 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, output should not be barred and button 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] [URL] Starting work on a URL spec

2010-07-23 Thread Boris Zbarsky


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] several messages

On Thu, 18 Mar 2010, Simon Pieters wrote:
On Thu, 18 Mar 2010 01:03:33 +0100, Ian Hickson i...@hixie.ch 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, div data-=foo 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, div data-=foo 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] 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] Constraint validation for maxlength

2010-07-23 Thread Aryeh Gregor

On Thu, Jul 22, 2010 at 5:46 PM, Jonas Sicking jo...@sicking.cc 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] HTMLMediaElement.preload and stalled event

2010-07-23 Thread Chris Pearce


 On 23/07/2010 8:57 p.m., Philip Jägenstedt wrote:
On Fri, 23 Jul 2010 05:25:37 +0200, Chris Pearce ch...@pearce.org.nz 
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] video resource selection algorithm and NETWORK_NO_SOURCE

2010-07-23 Thread Chris Pearce


 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] Question about the application/x-www-form-urlencoded encoding algorithm