Re: [whatwg] deprecating

[henry.st...@bblfish.net]

> On 2 Sep 2015, at 14:56, Philip Jägenstedt  wrote:
> 
> On Wed, Sep 2, 2015 at 1:00 PM, henry.st...@bblfish.net
>  wrote:
>> 
>>> On 1 Sep 2015, at 19:56, Ian Hickson  wrote:
>>> 
>>> As far as I can tell, therefore, things here are working exactly as one
>>> should expect.
>> 
>> Indeed: they seem to be working as one would expect where one thinking that 
>> forces
>> that don't like asymetric key cryptography to be widely deployed were trying 
>> to
>> remove that capability as far as possible. The manner of doing this - by 
>> secret
>> evidence, and pointers to closed non deployed standards - seems to be very 
>> much
>> the way of doing of organisations that like to keep things secret and closed.
> 
> This is borderline conspiratorial and is really not helpful. The first
> message in the blink-dev thread [1] nicely summarizes the motivation.
> If you distrust that and think that something more sinister is going
> on, fine, but that's no way to have a fruitful discussion.
> 
> Lots of things have been removed from specs and implementations
> following roughly the same "process", which is that some implementor
> realizes that they'd like to remove something, check if other
> implementors are on board, and then ask to have the spec changed.
> 
> [1] 
> https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/kmHsyMGJZAMJ

I sent a more detailed e-mail to the TAG where I think the discussion has per 
force moved to 
https://lists.w3.org/Archives/Public/www-tag/2015Sep/0010.html


> 
> Philip

Social Web Architect
http://bblfish.net/

Re: [whatwg] VIDEO and pitchAdjustment

[Michael Enright]

I'm an implementer (to the fullest extent that one can be one by
modifying existing open source), just following the convention of this
list of stating my use case. The use case reflects reality since it
was implemented last year.

On Mon, Aug 31, 2015 at 12:04 PM, Domenic Denicola  wrote:
> To be clear:
>
> Everyone can imagine use cases for playing videos backward. However, so far 
> the only statements we have about implementations are negative. My subthread 
> was more concerned with making the spec reflect current reality. If you can 
> convince implementers to support backward videos, then that's separate, and 
> we can change the spec again.
>

Re: [whatwg] deprecating

[henry.st...@bblfish.net]

> On 1 Sep 2015, at 19:56, Ian Hickson  wrote:
> 
> On Tue, 1 Sep 2015, henry.st...@bblfish.net wrote:
>> 
>> As the WhatWG only recenly moved to Github members here may not have 
>> noticed that  has been deprecated.
>> 
>> I opened https://github.com/whatwg/html/issues/67 to give space for the 
>> discussion. It is a pitty that this was closed so quickly ( within an 
>> hour ) without giving members and the public ( the users of the web ) 
>> time to comment nor for their voice to be heard.
>> 
>> This is a complex issue that involves many different levels of 
>> expertise, and it should not be handled so lightly.
> 
> The spec just reflects implementations. The majority of implementations of 
>  (by usage) have said they want to drop it,

There was a lot of pushback on those lists against dropping it, and no
clear arguments have been made for dropping keygen there.

> and the other major  implementation has never supported it.

You mean IE? IE has always had something that did the same:
 
https://msdn.microsoft.com/en-us/library/aa374863(VS.85).aspx

It is not idea, and it is easy to use both.

> The element was originally (and for 
> many years) purely a mostly-undocumented proprietary extension;

Adopted by most browsers. ( With IE having a similar feature just
done differently )

> at the 
> time it was invented, the HTML spec was edited by the W3C and the W3C did 
> not add it (they only ended up speccing it in their most recent HTML spec 
> because they forked the WHATWG's spec which did define it -- indeed, even 
> then, it was something that W3C HTML working group members argued should 
> not have been included). It was only added to the WHATWG spec because one 
> of the browser vendors said they could not remove support for it due to 
> usage by enterprise customers; that browser vendor is now amongst one of 
> the ones wanting to drop it.

To replace it with what? That is the problem that needs discussing and not 
partially
across twenty lists where the issues are only ever half addressed. 

> As far as I can tell, therefore, things here are working exactly as one 
> should expect.

Indeed: they seem to be working as one would expect where one thinking that 
forces
that don't like asymetric key cryptography to be widely deployed were trying to
remove that capability as far as possible. The manner of doing this - by secret 
evidence, and pointers to closed non deployed standards - seems to be very much
the way of doing of organisations that like to keep things secret and closed.

> 
> It's worth noting that  is a pretty terrible API. I recommend 
> approaching the groups writing new cryptography APIs, explaining your use 
> cases, and making sure they are supported in up-and-coming, more widely 
> supported, more secure, and more well-thought-out APIs.

The case has been made that things should go the other way around: the problems
should be brought up, and then improvements or replacements found. When those 
are
found and are satisfactory ( as evaluated against a wider set of values that 
take
the whole web security into account ) then one moves forward.



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

Social Web Architect
http://bblfish.net/

Re: [whatwg] deprecating

[Philip Jägenstedt]

On Wed, Sep 2, 2015 at 1:00 PM, henry.st...@bblfish.net
 wrote:
>
>> On 1 Sep 2015, at 19:56, Ian Hickson  wrote:
>>
>> As far as I can tell, therefore, things here are working exactly as one
>> should expect.
>
> Indeed: they seem to be working as one would expect where one thinking that 
> forces
> that don't like asymetric key cryptography to be widely deployed were trying 
> to
> remove that capability as far as possible. The manner of doing this - by 
> secret
> evidence, and pointers to closed non deployed standards - seems to be very 
> much
> the way of doing of organisations that like to keep things secret and closed.

This is borderline conspiratorial and is really not helpful. The first
message in the blink-dev thread [1] nicely summarizes the motivation.
If you distrust that and think that something more sinister is going
on, fine, but that's no way to have a fruitful discussion.

Lots of things have been removed from specs and implementations
following roughly the same "process", which is that some implementor
realizes that they'd like to remove something, check if other
implementors are on board, and then ask to have the spec changed.

[1] 
https://groups.google.com/a/chromium.org/d/msg/blink-dev/pX5NbX0Xack/kmHsyMGJZAMJ

Philip