Re: [whatwg] Device Element

[Diego Perini]

On Mon, Jan 3, 2011 at 11:28 PM, Glenn Maynard  wrote:
> On Mon, Jan 3, 2011 at 4:45 PM, Diego Perini  wrote:
>> You are correct, Firefox doesn't implement serial access by itself, it
>> just let me use the OS directly (if security configuration
>> restrictions are removed).
>
> Please remember that HTML5 file access does not give you a
> general-purpose serial API, regardless of whether you can access the
> serial device.  Accessing block devices (including regular files) is
> different from accessing character devices (eg. serial devices).

True but in case of character devices which continuously send a string
of max 1Kb (or less) this is not a blocking factor.

I agree that having a full set of API to handle b/c devices would be
everybody dream but we all know we have to work around some
limitations, it has always been so.

> HTML5 file APIs assume files have properties of block devices
> (seekable, with a meaningful size), and don't provide any of the
> critical APIs for character devices: true nonblocking reads
> (FileReader does async reads, which aren't the same thing);
> notification when data is available (again, not the same as

Polling for changes was enough to get the results but some sort of
mutation events would have worked better (depending on device output).

Currently the GPS device I am using only output text but it could as
well generate better data for parsing, like XML or your preferred one.

> FileReader's onprogress event).  And that's ignoring all of the
> important nitty details of serial devices, like port speed and other
> parameters.

Setting the device serial configuration can be done outside the
browser (until a proper specification and API exists). Maybe having
those settings in the "about:config" would allow access more easily to
those not willing to open the terminal.

Adding strong security will not diminish the importance of having
these capabilities in new OS centric browsers.

>
> I suspect you're hitting far more "happens-to-work" with what you're
> doing than you realize.
>

Yeah, maybe. However if you had payed attention to the discussion I am
just testing :)

I repeatedly stated that I am OK with current level of security and I
wish better and more secure methods are found and implemented (if
needed).

I added that I agree with the proposal to find alternatives that will
allow to make easy for browsers to communicate with RS232/USB devices
securely.

>> So next question is why allow Adobe Flash and plug-ins in general to
>> do that wildly and not allow others to have the same capability and be
>> so paranoid about security when that is already broken by other means
>> at higher levels ?
>
> Flash is insecure, so HTML5 should be too?  Seriously?
>

Please read it again I only asked "why" ?

I said Flash is insecure yes, the rest are your words (purposely
misinterpreted)...

HTML5 should be secure but I am not sure allowing it to run side by
side with insecure (and evil) content makes that a reality :-)

The "Device element" proposal and the parts on security that Seth put
forth in previous messages seemed a good start to me, that's all.

Have fun,

--
Diego


> --
> Glenn Maynard
>

Re: [whatwg] Fwd: RE: Inconsistent behaviour of globalCompositeOperation property

[Robert O'Callahan]

On Tue, Jan 4, 2011 at 7:25 AM,  wrote:

>  I thought that the issue was settled as well, but after talking to Ian
> Hixie and Philip Taylor, Ian indicated that if someone provides a clear
> formulation of the spec text that matches webkit behavior, the spec would
> likely be changed to match that.
> I have proposed the changes below, but got no reply (or if I got any I
> missed them):
>

Sorry, I should have replied earlier.

 HTML5 - Canvas.
>
> I have read this thread (from and of July 2010) and I happen to agree that
> the Safari/Chromium implementation is more intuitive, and likely less
> expensive to implement, therefore I offer these 2 proposals for changing the
> spec's Drawing model section to match what I perceive to be the preference
> of most people in that discussion.
>
> Of note: According to the current Drawing model, an opaque shape's shadow
> would be erased as part of step 6 when drawn with source-in composite Mode
> if globalAlpha is 1, which is probably not the intended behavior.
>
> Version 1:
>
> 4.8.11.1.13 Drawing model
>
>
>
> When a shape or image is painted, user agents must follow these steps, in
> the order given (or act as if they do):
>
> 1. Render the shape or image onto an infinite transparent black bitmap,
> creating image M1, as described in the previous sections except that for the
> purpose of this step every pixel of the image will be considered to be fully
> opaque white and the current fillStyle will be considered to be solid fully
> opaque white and the strokeStyle will be considered fullyOpaque white as
> well
>
2. When shadows are drawn, render the shadow from image M1, using a fully
> opaque white shadow color as described in the shadows section, creating
> image M2.
>
3. Let C1 be a region obtained by intersecting the canvas's cliping region
> with the set of pixels in the canvas that correspond to pixels in M1 (by
> having the same coordinates) that are not fully transparent.
>
> 4. Let C2 be a region obtained by intersecting the canvas's cliping region
> with the set of pixels in the canvas that correspond to pixels in M2 (by
> having the same coordinates) that are not fully transparent.
>
5. Render the shape or image onto an infinite transparent black bitmap,
> creating image A, as described in the previous sections. For shapes, the
> current fill, stroke, and line styles must be honored, and the stroke must
> itself also be subjected to the current transformation matrix.
>
> 6. When shadows are drawn, render the shadow from image A, using the
> current shadow styles, creating image B.
>
> 7. When shadows are drawn, multiply the alpha component of every pixel in B
> by globalAlpha.
>
> 8. When shadows are drawn, composite B with the current canvas bitmap,
> cliping results to region C2 defined above, using the current composition
> operator.
>
> 9. Multiply the alpha component of every pixel in A by globalAlpha.
>
> 10. Composite A with the current canvas bitmap, cliping results to region
> C1 defined above, using the current composition operator.
>

Making a binary fully-transparent/not-fully-transparent per-pixel decision
to create regions C1 and C2 seems like it can't be right in the presence of
antialiasing.

Suppose we have a path filled with black and operator "copy". Any pixel on
the edge of that path that gets any nonzero coverage value from antialiasing
will end up solid black with this proposal. That's going to look very ugly.
We'll want a solution where any canvas pixel which has a very small amount
of coverage by the path will be mostly unchanged in the final result.

Version 2:
>
>
>
> 4.8.11.1.13 Drawing model
>
>
>
> When a shape or image is painted, user agents must follow these steps, in
> the order given (or act as if they do):
>
> 1. Render the shape or image onto an infinite transparent black bitmap,
> creating image A, as described in the previous sections. For shapes, the
> current fill, stroke, and line styles must be honored, and the stroke must
> itself also be subjected to the current transformation matrix.
>
> 2. When shadows are drawn, render the shadow from image A, using the
> current shadow styles, creating image B.
>
> 3. When shadows are drawn, multiply the alpha component of every pixel in B
> by globalAlpha.
>
> 4. When shadows are drawn, composite, using the current composition
> operator, B with the current canvas bitmap, cliping results to the cliping
> region of the canvas and to the pixels that would have taken the shadow's
> color if the composition operator would have been source-over and the shadow
> would have been fully opaque and the globalAlpha would have been 1.
>
> 5. Multiply the alpha component of every pixel in A by globalAlpha.
>
> 6. Composite, using the current composition operator, A with the current
> canvas bitmap, cliping results to the cliping region of the canvas and to
> the pixels that would have taken the shape's or image's pixel color if the
> composition operator would have been source-over and

Re: [whatwg] Device Element

[Aryeh Gregor]

On Mon, Jan 3, 2011 at 4:45 PM, Diego Perini  wrote:
> So next question is why allow Adobe Flash and plug-ins in general to
> do that wildly and not allow others to have the same capability and be
> so paranoid about security when that is already broken by other means
> at higher levels ?

If something is available in HTML, any website can run it.  Websites
can't just install plugins.  The only way for them to install plugins
is by getting the user to run an executable, which browsers put lots
of scary "be careful" signs around just like for any other downloaded
executable.  If the website can get the user to install a plugin, it
can get them to run any program, so there's no security at all from
that point forward.

Yes, HTML features can require user confirmation, like geolocation
usually does.  But the kind of mild confirmation needed for
geolocation is not suitable for allowing arbitrary file read/write
access.  The latter would require much scarier-looking permission, in
fact about as much as installing a program, since it would be trivial
to escalate to arbitrary code execution.  We don't want to encourage
websites to pop up warnings like that all the time, because 1) many
users won't give permission, which makes the feature much less useful
to authors; and 2) it desensitizes users so they click yes all the
time.

So this is really apples and oranges.  Part of the point of the web is
it's relatively safe.  You can't compare web platform features to
arbitrary code like plugins.  This sort of feature will probably come
in time, driven by Chrome OS if nothing else, but it will have to be
thought out carefully to balance security against usability.

Re: [whatwg] Device Element

[Glenn Maynard]

On Mon, Jan 3, 2011 at 4:45 PM, Diego Perini  wrote:
> You are correct, Firefox doesn't implement serial access by itself, it
> just let me use the OS directly (if security configuration
> restrictions are removed).

Please remember that HTML5 file access does not give you a
general-purpose serial API, regardless of whether you can access the
serial device.  Accessing block devices (including regular files) is
different from accessing character devices (eg. serial devices).
HTML5 file APIs assume files have properties of block devices
(seekable, with a meaningful size), and don't provide any of the
critical APIs for character devices: true nonblocking reads
(FileReader does async reads, which aren't the same thing);
notification when data is available (again, not the same as
FileReader's onprogress event).  And that's ignoring all of the
important nitty details of serial devices, like port speed and other
parameters.

I suspect you're hitting far more "happens-to-work" with what you're
doing than you realize.

> So next question is why allow Adobe Flash and plug-ins in general to
> do that wildly and not allow others to have the same capability and be
> so paranoid about security when that is already broken by other means
> at higher levels ?

Flash is insecure, so HTML5 should be too?  Seriously?

-- 
Glenn Maynard

Re: [whatwg] Timed tracks: feedback compendium

[Aryeh Gregor]

On Mon, Jan 3, 2011 at 3:40 PM, Glenn Maynard  wrote:
> By the way, the WebSRT hit from Google
> (http://www.whatwg.org/specs/web-apps/current-work/websrt.html) is
> 404.  I've had to read it out of the Google cache, since I'm not sure
> where it went.

The format was renamed to WebVTT:

http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#webvtt-0

Re: [whatwg] Low Memory Event

[Bjartur Thorlacius]

On 1/2/11, Aryeh Gregor  wrote:
> Moreover, who says you're using a browser that puts different tabs in
> different threads; that that browser would still work correctly if you
> suspend a single thread and leave the others running; and that you
> even know that it's possible to suspend processes?  (Windows doesn't
> even give the option in its default GUIs, last I checked, although
> it's possible to do.)
>
As the system's clearly capable of multi-tasking, I figured it managed tasks.

I did misunderstand timeless'  email and applied his argument to off-line
gaming as well.

I don't understand why a server would rather waste resources on you "if
you're just flipping away for a bit," but sending and receiving noop packets to
and from the server, than if you simply "flip away"?

Re: [whatwg] Device Element

[Bjartur Thorlacius]

On 1/3/11, Boris Zbarsky  wrote:
> On 1/3/11 7:47 AM, Diego Perini wrote:
>> Mostly I am looking for other browser to implement this serial access
>> like Firefox does
>
> Firefox doesn't implement "serial access".  It just reads files.  What's
> exposed as "files" on a Unix system can be ... extensive (witness /proc
> on Linux, say).  It's up to the kernel.
>
This should be leveraged. Standardized API for file access and
standardized file names are a powerful combination. Sysadmins/users
can block or grant access to files, without even informing the browser of
the criteria or how requests are evaluated.

>>> For example can Flash overcome this restriction and access the
>> devices through the "file:" protocol ?
>
> Of course, if the kernel exposes them as files.
>
Or a userspace abstractions, such as KIO. For those with a KDE bent
of mind.

Re: [whatwg] Device Element

[Diego Perini]

On Mon, Jan 3, 2011 at 7:47 PM, Boris Zbarsky  wrote:
> On 1/3/11 7:47 AM, Diego Perini wrote:
>>
>> I am switching that bit on/off when I need it (and the RS232/USB
>> device is connected), I am not asking others to do it.
>
> So while it's off, the user is vulnerable.  Is the software doing this a
> Firefox extension?
>

No no... haven't tried that route but I understand it is another possibility.

I don't remember having said I use this bit for some real application,
just testing.

>> Mostly I am looking for other browser to implement this serial access
>> like Firefox does
>
> Firefox doesn't implement "serial access".  It just reads files.  What's
> exposed as "files" on a Unix system can be ... extensive (witness /proc on
> Linux, say).  It's up to the kernel.
>

You are correct, Firefox doesn't implement serial access by itself, it
just let me use the OS directly (if security configuration
restrictions are removed).

So let's say I like the functionality this happens to give me with
RS232/USB devices. Even with those restrictions in place.

This is why I agree with the request for a device interface
specification (in HTML5) that will make this inter-operable.

>> This also means limit what other plug-ins can currently do on user
>> machines
>
> Plug-ins are running native code.  They can't be limited unless you sandbox
> the process they're in completely (which typically breaks plug-ins; talk to
> Google about the pains they had to go to to sandbox Flash, even _with_
> Adobe's cooperation).
>
>> For example can Flash overcome this restriction and access the
>> devices through the "file:" protocol ?
>
> Of course, if the kernel exposes them as files.
>

So next question is why allow Adobe Flash and plug-ins in general to
do that wildly and not allow others to have the same capability and be
so paranoid about security when that is already broken by other means
at higher levels ?


--
Diego


> -Boris
>

Re: [whatwg] Timed tracks: feedback compendium

[Glenn Maynard]

By the way, the WebSRT hit from Google
(http://www.whatwg.org/specs/web-apps/current-work/websrt.html) is
404.  I've had to read it out of the Google cache, since I'm not sure
where it went.

On Mon, Jan 3, 2011 at 10:57 AM, Philip Jägenstedt  wrote:
>> But what's the use case? Is it really useful to have comments in a
>> subtitle file?
>
> Being able to put licensing/contact information at the top of the file would
> be useful, just as it is in JavaScript/CSS.

Inline comments (not just line comments) in subtitles are very
important for collaborative editing: for leaving notes about a
translation, noting where editing is needed or why a change was made,
and so on.

If a DOM-like interface is specified for this (presumably this will
happen later), being able to access inline comments like DOM comment
nodes would be very useful for visual editors, to allow displaying
comments and to support features like "seek to next comment".

-- 
Glenn Maynard

Re: [whatwg] Device Element

[Boris Zbarsky]

On 1/3/11 7:47 AM, Diego Perini wrote:

I am switching that bit on/off when I need it (and the RS232/USB
device is connected), I am not asking others to do it.


So while it's off, the user is vulnerable.  Is the software doing this a 
Firefox extension?



Mostly I am looking for other browser to implement this serial access
like Firefox does


Firefox doesn't implement "serial access".  It just reads files.  What's 
exposed as "files" on a Unix system can be ... extensive (witness /proc 
on Linux, say).  It's up to the kernel.



This also means limit what other plug-ins can currently do on user machines


Plug-ins are running native code.  They can't be limited unless you 
sandbox the process they're in completely (which typically breaks 
plug-ins; talk to Google about the pains they had to go to to sandbox 
Flash, even _with_ Adobe's cooperation).



For example can Flash overcome this restriction and access the
devices through the "file:" protocol ?


Of course, if the kernel exposes them as files.

-Boris

Re: [whatwg] Fwd: RE: Inconsistent behaviour of globalCompositeOperation property

[carol.szabo]

I thought that the issue was settled as well, but after talking to Ian Hixie 
and Philip Taylor, Ian indicated that if someone provides a clear formulation 
of the spec text that matches webkit behavior, the spec would likely be changed 
to match that.
I have proposed the changes below, but got no reply (or if I got any I missed 
them):

TML5 - Canvas.

I have read this thread (from and of July 2010) and I happen to agree that the 
Safari/Chromium implementation is more intuitive, and likely less expensive to 
implement, therefore I offer these 2 proposals for changing the spec's Drawing 
model section to match what I perceive to be the preference of most people in 
that discussion.

Of note: According to the current Drawing model, an opaque shape's shadow would 
be erased as part of step 6 when drawn with source-in composite Mode if 
globalAlpha is 1, which is probably not the intended behavior.

Version 1:

4.8.11.1.13 Drawing model



When a shape or image is painted, user agents must follow these steps, in the 
order given (or act as if they do):

1. Render the shape or image onto an infinite transparent black bitmap, 
creating image M1, as described in the previous sections except that for the 
purpose of this step every pixel of the image will be considered to be fully 
opaque white and the current fillStyle will be considered to be solid fully 
opaque white and the strokeStyle will be considered fullyOpaque white as well.

2. When shadows are drawn, render the shadow from image M1, using a fully 
opaque white shadow color as described in the shadows section, creating image 
M2.

3. Let C1 be a region obtained by intersecting the canvas's cliping region with 
the set of pixels in the canvas that correspond to pixels in M1 (by having the 
same coordinates) that are not fully transparent.

4. Let C2 be a region obtained by intersecting the canvas's cliping region with 
the set of pixels in the canvas that correspond to pixels in M2 (by having the 
same coordinates) that are not fully transparent.

5. Render the shape or image onto an infinite transparent black bitmap, 
creating image A, as described in the previous sections. For shapes, the 
current fill, stroke, and line styles must be honored, and the stroke must 
itself also be subjected to the current transformation matrix.

6. When shadows are drawn, render the shadow from image A, using the current 
shadow styles, creating image B.

7. When shadows are drawn, multiply the alpha component of every pixel in B by 
globalAlpha.

8. When shadows are drawn, composite B with the current canvas bitmap, cliping 
results to region C2 defined above, using the current composition operator.

9. Multiply the alpha component of every pixel in A by globalAlpha.

10. Composite A with the current canvas bitmap, cliping results to region C1 
defined above, using the current composition operator.



Version 2:

4.8.11.1.13 Drawing model



When a shape or image is painted, user agents must follow these steps, in the 
order given (or act as if they do):

1. Render the shape or image onto an infinite transparent black bitmap, 
creating image A, as described in the previous sections. For shapes, the 
current fill, stroke, and line styles must be honored, and the stroke must 
itself also be subjected to the current transformation matrix.

2. When shadows are drawn, render the shadow from image A, using the current 
shadow styles, creating image B.

3. When shadows are drawn, multiply the alpha component of every pixel in B by 
globalAlpha.

4. When shadows are drawn, composite, using the current composition operator, B 
with the current canvas bitmap, cliping results to the cliping region of the 
canvas and to the pixels that would have taken the shadow's color if the 
composition operator would have been source-over and the shadow would have been 
fully opaque and the globalAlpha would have been 1.

5. Multiply the alpha component of every pixel in A by globalAlpha.

6. Composite, using the current composition operator, A with the current canvas 
bitmap, cliping results to the cliping region of the canvas and to the pixels 
that would have taken the shape's or image's pixel color if the composition 
operator would have been source-over and the image would have been fully 
opaque, the fillStyle and strokeStyle would have been a solid fully opaque 
color, and the globalAlpha would have been 1.



I also suggest, this change to section 4.8.11.1.3 Compositing:

Instead of:

The operators in the above list must be treated as described by the Porter-Duff 
operator given at the start of their description (e.g. A over B). They are to 
be applied as part of the drawing model, at which point the clipping region is 
also applied. (Without a clipping region, these operators act on the whole 
bitmap with every operation.) [PORTERDUFF]

Say:

The operators in the above list must be treated as described by the Porter-Duff 
operator [PORTERDUFF] given at the start of their description

Re: [whatwg] Timed tracks: feedback compendium

[Craig S. Kiessling]

Can someone please let me know how to unsubscribe? Many thanks.

Sincerely,

Craig S. Kiessling
www.PathsAtlanta.org  - Martial Arts & More
www.CSKnet.net  - SEO & More
/www.AtlantaMahjong.com  - The Mahjong Source
in Atlanta

Connect with Me
http://www.csknet.net/Contact/





On Mon, Jan 3, 2011 at 12:56 PM, Simon Pieters  wrote:

> On Mon, 03 Jan 2011 16:57:50 +0100, Philip Jägenstedt 
> wrote:
>
>  To use a different style for the cues that are sung together, so that
 you know when it's your turn to sing.

>>>
>>> It's not clear whether multiple voices is really necessary. Can't you
>>> just
>>> do (using the new syntax):
>>>
>>>  00:01.000 --> 00:02.000
>>>   Speaker 1
>>> 00:03.000 --> 00:04.000
>>>   Speaker 2
>>> 00:05.000 --> 00:06.000
>>>   Speaker 1+2
>>>
>>> ...where "Bob and Jim" is a third name?
>>>
>>
>> Sure, one could, but the new syntax/parsing also allows 
>> Speaker 1+2, which is what I requested.
>>
>> Using this syntax, I would expect some confusion when you omit the closing
>> , when it's *not* a cue spoken by two voices at the same time, such as:
>>
>> - Boo!
>> - Gah!
>>
>> Gah! is spoken by both Jim and Bob, but that was likely not intended. If
>> this causes confusion, we should make validators warn about multiple voices
>> with with no closing .
>>
>
> Or we can say that nesting cues is not important enough to be supported,
> and make  imply ?
>
> --
> Simon Pieters
> Opera Software
>

Re: [whatwg] Timed tracks: feedback compendium

[Simon Pieters]

On Mon, 03 Jan 2011 16:57:50 +0100, Philip Jägenstedt   
wrote:



To use a different style for the cues that are sung together, so that
you know when it's your turn to sing.


It's not clear whether multiple voices is really necessary. Can't you  
just

do (using the new syntax):

 00:01.000 --> 00:02.000
  Speaker 1
00:03.000 --> 00:04.000
  Speaker 2
00:05.000 --> 00:06.000
  Speaker 1+2

...where "Bob and Jim" is a third name?


Sure, one could, but the new syntax/parsing also allows   
Speaker 1+2, which is what I requested.


Using this syntax, I would expect some confusion when you omit the  
closing , when it's *not* a cue spoken by two voices at the same  
time, such as:


- Boo!
- Gah!

Gah! is spoken by both Jim and Bob, but that was likely not intended. If  
this causes confusion, we should make validators warn about multiple  
voices with with no closing .


Or we can say that nesting cues is not important enough to be supported,  
and make  imply ?


--
Simon Pieters
Opera Software

Re: [whatwg] :invalid

[Benjamin Poulain]

On 12/31/2010 02:13 AM, ext Ian Hickson wrote:

It's not entirely clear to me what the intended UI is here. If the goal is
to only style form elements for (in)validity after they've lost focus or
after their form is submitted, it seems a couple of scripts on
would be the way to go:



...along with CSS rules like:

.examined:invalid { ... }
.examined:out-of-range { ... }


On Thu, 23 Sep 2010, Boris Zbarsky wrote:


Are there cases when pages would set invalid default values and want
them flagged as such in UI?


On Fri, 24 Sep 2010, Shiv Kumar wrote:


Typically, in large organizations, there are folks who clean up data. So
they will be presented with data that's already entered by someone else
and their job is to clean up the data. In fact I see the new Form API to
be a very good candidate for this use case.


Indeed.


Isn't that targeting the wrong audience?

I think the use case you solve with .examined:invalid is quite common.

On the other side, batch clean up of data is a special case for 
enterprises. And can image those systems validate on server side and 
would not benefit much from :invalid.


cheers,
Benjamin

Re: [whatwg] Timed tracks: feedback compendium

[Philip Jägenstedt]

On Sat, 25 Dec 2010 07:39:02 +0100, Ian Hickson  wrote:


 + I've made  have a feature whereby a track can be enabled by
   default so that users who would otherwise not have any tracks enabled
   will get it enabled (without overriding the preferences of users who
   would have some other track enabled by default).


For the lazy, it's , see  
http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#attr-track-default



   text/vtt respectively.
 + I've added a magic string that is required on the format to make it
   recognisable in environments with no or unreliable type labeling.


Is there a reason it's "WEBVTT FILE" instead of just "WEBVTT"? "FILE"  
seems redundant and like unnecessary typing to me.



On Wed, 8 Sep 2010, Sam Dutton wrote:

>>
>> Also -- is trackgroup out of the spec?
>
> What is trackgroup?

I'd seen this in the Media TextAssociations documentation:

http://www.w3.org/WAI/PF/HTML/wiki/Media_TextAssociations#Examples


The feature is mostly there, it's just expressed differently (it's done  
in
a way similar to how  works: you specify all the relevant  
attributes

on each ).


On Wed, 8 Sep 2010, Philip Jägenstedt wrote:


In the discussion on public-html-a11y  was suggested to
group together mutually exclusive tracks, so that enabling one
automatically disables the others in the same trackgroup.

I guess it's up to the UA how to enable and disable s now, but
the only option is making them all mutually exclusive (as existing
players do) or a weird kind of context menu where it's possible to
enable and disable tracks completely independently. Neither options is
great, but as a user I would almost certainly prefer all tracks being
mutually exclusive and requiring scripts to enable several at once.


It's not clear to me what the use case is for having multiple groups of
mutually exclusive tracks.

The intent of the spec as written was that a browser would by default  
just

have a list of all the subtitle and caption tracks (the latter with
suitable icons next to them, e.g. the [CC] icon in US locales), and the
user would pick one (or none) from the list. One could easily imagine a  
UA

allowing the user to enable multiple tracks by having the user ctrl-click
a menu item, though, or some similar solution, much like with the  
commonly

seen select box UI.


In the vast majority of cases, all tracks are intended to be mutually  
exclusive, such as English+English HoH or subtitles in different  
languages. No media player UI (hardware or software) that I have ever used  
allows enabling multiple tracks at once. Without any kind of hint about  
which tracks make sense to enable together, I can't see desktop Opera  
allowing multiple tracks (of the same kind) to be enabled via the main UI.



> On Fri, 6 Aug 2010, Philip Jägenstedt wrote:
> >
> > I'm not particularly fond of the current voice markup, mainly for 2
> > reasons:
> >
> > First, a cue can only have 1 voice, which makes it impossible to
> > style cues spoken/sung simultaneously by 2 or more voices. There's a
> > karaoke example of this in
> >  


>
> That's just two cues.

I'm not sure what you're saying. The male singer's cues are in blue, the
female singer's are in red and the part sung together is in green. Are
you saying that the last cue should be made into two cues, or something
else?


I would just have the three be labeled as three different voices. (I
thought you were referring to two people saying two different things on
the screen at the same time, which would be two cues.)



> > I would prefer if voices could be mixed, as such:
> >
> > 00:01.000 --> 00:02.000
> > <1> Speaker 1
> >
> > 00:03.000 --> 00:04.000
> > <2> Speaker 2
> >
> > 00:05.000 --> 00:06.000
> > <1><2> Speaker 1+2
>
> What's the use case?

To use a different style for the cues that are sung together, so that
you know when it's your turn to sing.


It's not clear whether multiple voices is really necessary. Can't you  
just

do (using the new syntax):

 00:01.000 --> 00:02.000
  Speaker 1
00:03.000 --> 00:04.000
  Speaker 2
00:05.000 --> 00:06.000
  Speaker 1+2

...where "Bob and Jim" is a third name?


Sure, one could, but the new syntax/parsing also allows   
Speaker 1+2, which is what I requested.


Using this syntax, I would expect some confusion when you omit the closing  
, when it's *not* a cue spoken by two voices at the same time, such as:


- Boo!
- Gah!

Gah! is spoken by both Jim and Bob, but that was likely not intended. If  
this causes confusion, we should make validators warn about multiple  
voices with with no closing .



> On Tue, 24 Aug 2010, Philip Jägenstedt wrote:
> >
> > Here's the SRT research I promised:
> > http://blog.foolip.org/2010/08/20/srt-research/
>
> Awesome! Thanks for this.
>
> Addressing points in the same order:
>
> - charset: resolved by introducing a charset override.

Oh well, that's better

Re: [whatwg] Device Element

[Diego Perini]

On Mon, Jan 3, 2011 at 8:12 AM, Boris Zbarsky  wrote:
> On 1/2/11 2:51 PM, Diego Perini wrote:
>>
>> Of course this require file security privileges
>> (security.fileuri.strict_origin_policy = true)
>
> You mean false.
>

Yes, need to set that to "false" to have those privileges.

> That option is there for testing purposes only.  If you're asking users to
> change them, you're asking them to leave their browser exploitable. Please
> don't do that.
>

I am switching that bit on/off when I need it (and the RS232/USB
device is connected), I am not asking others to do it.

I hope this feature/capability does not disappear without alternatives
in next versions of Firefox (or next time I will just have to
shut-up).

Mostly I am looking for other browser to implement this serial access
like Firefox does, with security as one of the top objectives. This
also means limit what other plug-ins can currently do on user machines
! For example can Flash overcome this restriction and access the
devices through the "file:" protocol ?


--
Diego


> -Boris
>

Re: [whatwg] sic element, was: Re: Exposing spelling/grammar suggestions in contentEditable

[timeless]

On Mon, Jan 3, 2011 at 10:41 AM, Markus Ernst  wrote:
>> Would search engines benefit from markup for this?
>
> They could actually benefit, if the correct spelling would be added in an
> attribute, so they could match the misspelled word with a correctly spelled
> search term; somehow like:
> chuse

I doubt it. At this point search engines have better spell checking
and translation support than just about anything else, since they have
and use the largest corpora in the world.

http://www.google.com/search?q=chuse
http://www.usconstitution.net/constmiss.html

I can't get the cooler versions of this to work, but...

http://www.google.com/search?q=we+chuse
applies yields a search for we choose, and completion offers: we
choose to be bounded
"we chuse" suggests "we choose to go to the moon"

It's hard to do a useful search for this stuff,

searching for "But in chusing the President" or "But in choosing the
President" generally yields the same documents, e.g.
http://www.usconstitution.net/const.html

The reason of course is that the document has:
Article II - The Executive Branch
(... then from the five highest on the List the said House shall in
like Manner chuse the President. But in chusing the President, the
Votes shall be taken by States, ...) (This clause in parentheses was
superseded by the 12th Amendment.)

Amendment 12 - Choosing the President, Vice-President. Ratified
6/15/1804. Note History The Electoral College
... the House of Representatives shall choose immediately, by ballot,
the President. But in choosing the President, the votes shall be taken
by states, ...

I think in general search engines do not reward points for attributes
or similar things, because on average they're used more by spammers
than by hammers (if everything you have looks like a nail).

Adding sic's is nowhere near as valuable or useful as adding
replacement language or footnotes or end paragraph notes. sic's merely
interrupt reading.

FWIW, this morning I spent some time searching for "serveral", i
eventually settled on something like:
http://www.google.com/codesearch?hl=en&start=20&sa=N&q=serveral+-serveralert+-serveralias+-serverallowsresponsecachingforrequest+-serveralreadyactive+-serveralreadyregistered+-openssh+-serverallowsspawn

It isn't particularly useful, it turns out (using another search
engine) there was a version of tracker which had a message with this
misspelled, but as of 0.7.25 only outdated translations remember:
/tracker-0.7.25/po/pt_BR.po
line 2008 -- #~ "serveral minutes\n"
/tracker-0.7.25/po/sk.po
line 1988 -- #~ "serveral minutes\n"
/tracker-0.7.25/po/sv.po
line 2658 -- #~ "serveral minutes\n"
/tracker-0.7.25/po/b...@latin.po
line 1519 -- #~ "serveral minutes\n"
/tracker-0.7.25/po/ca.po
line 1522 -- #~ "serveral minutes\n"
/tracker-0.7.25/po/ko.po
line 739 -- "serveral minutes\n"

Now, you might want to find "several minutes" in tracker, but afaict,
that code doesn't exist, so you wouldn't have been searching for this
that way in the first place.

Re: [whatwg] sic element, was: Re: Exposing spelling/grammar suggestions in contentEditable

[Markus Ernst]

Am 31.12.2010 17:30 schrieb Benjamin Hawkes-Lewis:

On Fri, Dec 31, 2010 at 3:17 PM, Martin Janecke  wrote:

[snip]

Apart from informing human readers about the correct reproduction of a
misspelled word, a HTML  would indicate the same to web applications.
Think of a search engine, which, as one factor of their ranking algorithm,
considers orthography and grammar in a page as quality factor. The search
engine could be made to ignore (reasonably few)-marked errors in such
an algorithm; i.e. not let-marked errors rank the page lower.


Would search engines benefit from markup for this?


They could actually benefit, if the correct spelling would be added in 
an attribute, so they could match the misspelled word with a correctly 
spelled search term; somehow like:

chuse

This would probably lead to abuse by seo trickers:
buy my product!

Also, I assume that this search engine benefit can already be achieved 
with existing markup:

chuse