The current version disallows the size and maxlength attributes in input
elements when type="time", type="date", type="datetime",
type="datetime-local", type="number", type="range", or type="color" is used.
I suppose the reason is that for other new input types, browsers are
expected to use advan
On Tue, Feb 15, 2011 at 9:21 PM, Silvia Pfeiffer
wrote:
> I really don't think we need to make up something new for this - it
> already works as you requested. But I would in addition want line
> comments, just so you can comment out full cues or leave comments on
> cues.
Right; I mentioned this
On Wed, Feb 16, 2011 at 12:52 PM, Glenn Maynard wrote:
> On Tue, Feb 15, 2011 at 7:36 PM, Silvia Pfeiffer
> wrote:
>> Can you provide some good examples where mid-cue comments make sense?
>> I'm just wondering if it is really an 80% use case.
>
> Editors marking words and sentences that need
> at
On Tue, Feb 15, 2011 at 7:36 PM, Silvia Pfeiffer
wrote:
> Can you provide some good examples where mid-cue comments make sense?
> I'm just wondering if it is really an 80% use case.
Editors marking words and sentences that need
attention***, commenting on word selection
choice?, and so onetc. Ha
Can you provide some good examples where mid-cue comments make sense?
I'm just wondering if it is really an 80% use case.
I suppose, you can always do and then style it as
"display:none", but this would only work in a browser unless offline
caption applications start supporting style sheets or
b
On Tue, Feb 15, 2011 at 7:01 PM, Silvia Pfeiffer
wrote:
> I would prefer if we could stick with a line based approach to this
> issue and something that can be resolved without having to look at a
> style sheet. If we do it this way, it doesn't become a pre-processor
> type comment any more and le
On Tue, Feb 15, 2011 at 6:33 PM, Nicholas Zakas wrote:
> That being said, I think we're going a bit off-track now. Both Kyle's and my
> proposals are based on already-existing functionality that we know doesn't
> break the web (code hacks aside). We'd both like to formalize that behavior
> in s
On Wed, Feb 16, 2011 at 3:26 AM, Philip Jägenstedt wrote:
> On Tue, 15 Feb 2011 12:57:02 +0100, Glenn Maynard wrote:
>
>> Following up on a use case discussed earlier, an alternative approach
>> for adding mid-cue comments, such as editor notes, would be to wrap
>> them in a class: comment. It's
As much as I love you guys, please make sure that only one of my email
addresses is being used. I've had to remove my personal email address from this
thread at least twice and it keeps magically reappearing. :)
I do believe that preloading of style sheets is a very different use case than
prel
On 02/15/2011 12:44 PM, Philip Jägenstedt wrote:
On Tue, 15 Feb 2011 19:13:26 +0100, David Flanagan
wrote:
What about Document and Window? What's the justification for defining
the media event handler attributes on those objects?
Huh, it is on Window, I hadn't seen that before. They were adde
2011/2/15 Leandro Graciá Gil :
> Given the above case, we don't think that the lifetime of the Stream objects
> should be controlled exclusively by the Web application. We think that the
> specification should state "the UA must allow the user to explicitly revoke
> access". The API should then be
On Tue, Feb 15, 2011 at 11:26 AM, Philip Jägenstedt wrote:
>> Related to line breaking, should there be an escape? Inserting
>> nbsp literally into files is somewhat annoying for authoring, since
>> they're indistinguishable from regular spaces.
>
> I would kind of prefer not going down that pa
* Kornel Lesi?ski wrote:
>Change of default search engine may have security implications — there are
>less tech-savvy people who rely on search engine for *everything* they do
>on the net and blindly trust the results (see famous "facebook login"
>case).
(There are in fact many people who do
On Mon, 14 Feb 2011 21:34:27 -, David Levin wrote:
IsSearchProviderInstalled(string url) returns
* 2 if the origin in the given url is the default search provider
* 1 if the origin in the given url is a search provider but not the
default.
* 0 otherwise
If the given url doesn’t hav
Rather than trying to sum up all use cases I think that the media asset
should be fully random accessible and frame accurate to cover any current
and future us ecasse. You should be able to write Javascripts that tell the
asset to go to any point in time.
That way a web developer (or implementers
Returning to this discussion, I think it is lacking in use cases.
Consider the controllers we are used to - they tend to have frame step,
chapter step and some kind of scrub bar.
Frame stepping is used when you want to mark an accurate in or our point, or
catch a still frame. This needs to be acc
On Tue, 15 Feb 2011 19:13:26 +0100, David Flanagan
wrote:
On 02/15/2011 02:17 AM, Philip Jägenstedt wrote:
On Mon, 14 Feb 2011 22:54:54 +0100, David Flanagan
wrote:
The draft specification defines 20+ medial event handler IDL
attributes on HTMLElement. These events are non-bubbling and ar
Although I'm not aware of anyone wrapping a 250KB style-sheet in
comments, the pre-loading interface could seemingly be applied to any
number of elements. Nicholas' original e-mail referenced a blog post
by Stoyan Stefanov which details a way to pre-fetch both scripts and
stylesheets.
It's true
Ian Hickson (2010-12-07):
> On Thu, 26 Aug 2010, Christoph Päper wrote:
Sorry for replying late.
>> However, I believe the underlying problem is simply that “line break” is
>> (too) often used and understood as a synonym for “new line”, at least by
>> non-native speakers. Speaking of breaks on
While they are converging, I think the first proposal is simpler,
defines a much more generic interface with applicability beyond script
elements, provides a mechanism for opting into or out of the behavior,
and will lead to cleaner javascript and, unlike readyState, does not
introduce compatibilit
On 02/15/2011 02:17 AM, Philip Jägenstedt wrote:
On Mon, 14 Feb 2011 22:54:54 +0100, David Flanagan
wrote:
The draft specification defines 20+ medial event handler IDL
attributes on HTMLElement. These events are non-bubbling and are
always targeted at and tags, so I wonder if they
wouldn't b
On 2/14/11, David Levin wrote:
> Problem
> Although the default search provider may have a significant impact on a
> user’s web experience, it isn’t easy for users to set this.
>
> Ideally, a search engine should be able to offer the user the ability to
> easily use it as the default. Currently, t
Hi,
Looking at the current state of the specification I see there is no mention
about the expected lifetime of the stream objects, or to say it in another
way, the period in which a page can access the selected device data. We
would like to propose that the user can explicitly invalidate an existi
On Tue, 15 Feb 2011 12:57:02 +0100, Glenn Maynard wrote:
Following up on a use case discussed earlier, an alternative approach
for adding mid-cue comments, such as editor notes, would be to wrap
them in a class: comment. It's a little awkward, but has the
advantage of allowing the comments to
Following up on a use case discussed earlier, an alternative approach
for adding mid-cue comments, such as editor notes, would be to wrap
them in a class: comment. It's a little awkward, but has the
advantage of allowing the comments to be displayed within the
displayed captions just by changing t
Philip,
As promised here is the summarized list of things that after this
discussion I still think we should add/change:
* the file magic string should not be “WEBVTT FILE”, but “WEBVTT” only
(or alternatively "WebVTT", but typically magic identifiers are all
caps
* allow for name-value pairs as
On Tue, Feb 15, 2011 at 9:09 PM, Philip Jägenstedt wrote:
> On Tue, 15 Feb 2011 04:28:36 +0100, Silvia Pfeiffer
> wrote:
>
>> Hi Philip,
>>
>> On Tue, Feb 15, 2011 at 3:27 AM, Philip Jägenstedt
>> wrote:
>>>
>>> On Wed, 09 Feb 2011 03:57:37 +0100, Silvia Pfeiffer
>>> wrote:
>>>
>> A. Feedba
On Mon, 14 Feb 2011 22:54:54 +0100, David Flanagan
wrote:
The draft specification defines 20+ medial event handler IDL attributes
on HTMLElement. These events are non-bubbling and are always targeted
at and tags, so I wonder if they wouldn't be better
defined on HTMLMediaElement inste
On Tue, 15 Feb 2011 04:28:36 +0100, Silvia Pfeiffer
wrote:
Hi Philip,
On Tue, Feb 15, 2011 at 3:27 AM, Philip Jägenstedt
wrote:
On Wed, 09 Feb 2011 03:57:37 +0100, Silvia Pfeiffer
wrote:
A. Feedback on the WebVTT format
1. Introduce file-wide metadata
WebVTT requires a structure t
Kevin Marks schrieb am Tue, 15 Feb 2011 00:23:00
-0800:
> To be fair to Safari it supports far more audio formats than other
> browsers,
Yes, but it supports *other* formats than other browsers. That's the
crux of the issue. To creators of multimedia files and web developers
alike, having to pro
On Tue, 15 Feb 2011 03:48:10 +0100, Jens O. Meiert wrote:
It was that way before, but many pages were already using those
attributes and expected the browser to not do anything with them.
I understand that good judgment will have been applied. Hence out of
mere curiosity, do you happen to hav
On Mon, Feb 14, 2011 at 11:52 PM, Nils Dagsson Moskopp <
n...@dieweltistgarnichtso.net> wrote:
> Kevin Marks schrieb am Mon, 14 Feb 2011 22:33:13
> -0800:
>
> > On Mon, Feb 14, 2011 at 2:39 PM, Ian Hickson wrote:
> >
> > > […]
> > >
> > > I haven't added anything here yet, mostly because I've no
32 matches
Mail list logo
