First script is the most common thing to use to resolve relative URLs.
Some APIs do it differently because, well, the web platform is
awesome. I don't think there's any problem with using the interface's
document instead in this case.
Adam
On Thu, Dec 2, 2010 at 5:48 AM, Anne van Kesteren
To all WebSRT experts on this list:
I have done my best to contribute WebSRT examples to the bake-off
between TTML and WebSRT at
http://www.w3.org/WAI/PF/HTML/wiki/TextFormat_Mapping_to_Requirements
. I would highly appreciate it if people could review the WebSRT
examples I contributed there and
On Thu, Dec 2, 2010 at 9:53 PM, Benjamin Hawkes-Lewis
bhawkesle...@googlemail.com wrote:
Allowing UAs explicitly to provide information via dedicated optional
fields is different to requiring UAs them to leak it in the course of
providing another service (such as spelling).
It's worth noting
On Fri, Dec 3, 2010 at 12:07 AM, Charles Pritchard ch...@jumis.com wrote:
The red squigly [sic] lines current provided by proprietary IMEs do not
cater many uses:
They're meant to be generic, and they are. High contrast, large font, and
screen reading cases
all come up here.
If you make a
On Mon, Nov 29, 2010 at 6:05 PM, Charles Pritchard ch...@jumis.com wrote:
Has this list considered moving towards standards in 'chrome' extensions?
Not to my recollection.
It
seems that there is a lot of low-hanging fruit
that, while not exposed to untrusted scripts, could easily be
On 3 Dec 2010, at 00:16, Jonas Sicking wrote:
As a browser implementer, I can tell you I won't implement any
specification that isn't motivated by use cases. So I definitely think
you want to establish use cases if you're hoping to get browsers to
implement your suggestion.
The major use case
On Thu, 02 Dec 2010 23:56:33 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/2/10 2:31 PM, Daniel Veditz wrote:
On 12/1/10 7:29 AM, Boris Zbarsky wrote:
On 12/1/10 3:49 AM, Philip Jägenstedt wrote:
I dunno about solid, but the obvious things you can do with
javascript: that you can't do as
On Dec 2, 2010, at 6:00 , Diogo Resende wrote:
I don't think Don was talking about mouse/kb/video/gps stuff. That
should be handled by the OS and reflected to the current APIs as wired
alternatives do. I think Don meant to be able to scan other types of
devices and be able to interact with
On Fri, 2010-12-03 at 09:13 -0800, David Singer wrote:
But there is still a whole OS, and a piece of hardware (the bluetooth chip)
between the browser and the bluetooth device. If the OS considers the device
'visible' or 'connected' then it's available to the browser. It doesn't
matter what
On 12/3/2010 2:05 AM, Adrian Sutton wrote:
On 3 Dec 2010, at 00:16, Jonas Sicking wrote:
As a browser implementer, I can tell you I won't implement any
specification that isn't motivated by use cases. So I definitely think
you want to establish use cases if you're hoping to get browsers to
There is a lot of push back on this list regarding IME: I'd like to know the
boundaries of acceptable use cases.
Well, it depends on how you look at it. Your real use case is that
you want a webpage editor that supports IME, right? That is a very
good use case.
Less good is I want to build an
On 3 Dec 2010, at 20:41, Charles Pritchard wrote:
The major use case here remains being able to provide both spell checking as
you type and a customised context menu within rich text editors. Today that
is not possible on any browser that I know of and it's one of if not the
biggest
On 12/3/2010 1:34 PM, Jonas Sicking wrote:
There is a lot of push back on this list regarding IME: I'd like to know the
boundaries of acceptable use cases.
Well, it depends on how you look at it. Your real use case is that
you want a webpage editor that supports IME, right? That is a very
good
On 12/3/2010 1:38 PM, Adrian Sutton wrote:
On 3 Dec 2010, at 20:41, Charles Pritchard wrote:
The major use case here remains being able to provide both spell
checking as you type and a customised context menu within rich text
editors. Today that is not possible on any browser that I know of
On 3 Dec 2010, at 22:06, Charles Pritchard wrote:
Yes, I understand that.
Your statement relates to a defect in the current flexibility of the context
menu.
I fully understand that, you wouldn't need the context menu to be more
flexible, if you had access to suggestions, as you have
On 12/2/2010 4:16 PM, Jonas Sicking wrote:
On Thu, Dec 2, 2010 at 4:07 PM, Charles Pritchardch...@jumis.com wrote:
The red squigly [sic] lines current provided by proprietary IMEs do not
cater many uses:
They're meant to be generic, and they are. High contrast, large font, and
screen reading
On 12/3/2010 2:19 PM, Adrian Sutton wrote:
On 3 Dec 2010, at 22:06, Charles Pritchard wrote:
Yes, I understand that.
Your statement relates to a defect in the current flexibility of the
context menu.
I fully understand that, you wouldn't need the context menu to be
more flexible, if you
17 matches
Mail list logo
