Re: CFC: Request to move HTML5.1 to Candidate Recommendation (CR)

[Alexander Schmitz]

+1
Alexander Schmitz
jQuery Foundation


On Mon, Jun 6, 2016 at 8:31 AM, Ian Pouncey  wrote:
> +1
>
> On 2 June 2016 at 13:48, Léonie Watson  wrote:
>>
>> Hello WP,
>>
>> This is a call for consensus to request that W3C publish the current HTML
>> Working Draft (WD) as a Candidate Recommendation (CR). It has been posted
>> to
>> public-webapps@w3.org as the official email for this WG.
>>
>> Please reply to this thread on public-webapps@w3.org  no later than end of
>> day on 10 June. Positive responses are preferred and encouraged, silence
>> will be considered as assent.
>>
>> The current HTML5.1 WD [1] improves upon HTML5. It includes updates that
>> make it more reliable, more readable and understandable, and a better
>> match
>> for reality. Substantial changes between HTML5 and HTML5.1 can be found in
>> the spec [2].
>>
>> When a specification moves to CR it triggers a Call For Exclusions, per
>> section 4 of the W3C Patent Policy [3]. No substantive additions can be
>> made
>> to a specification in CR without starting a new Call for Exclusions, so we
>> will put HTML5.1 into "feature freeze". It is possible to make editorial
>> updates as necessary, and features marked "At Risk" may be removed if
>> found
>> not to be interoperable.
>>
>> The following features are considered "at risk". If we cannot identify at
>> least two shipping implementations, they will be marked "at risk" in the
>> CR
>> and may be removed from the Proposed Recommendation.
>>
>> keygen element. [issue 43]
>> label as a reassociatable element [issue 109]
>> Fixing requestAnimationFrame to 60Hz, not implementation-defined [issues
>> 159/375/422]
>> registerContentHandler [Issue 233]
>> inputmode attribute of the input element [issue 269]
>> autofill of form elements [issue 372]
>> menu, menuitem and context menus. [issue 373]
>> dialog element [issue 427]
>> Text tracks exposing in-band metadata best practices [Issue 461]
>> datetime and datatime-local states of the input element [Issue 462]
>>
>> Please share implementation details for any of these features on Github.
>> To
>> mark other features "at risk", please identify them by 10th June (ideally
>> by
>> filing an issue and providing a test case).
>>
>> At the same time we move HTML5.1 into CR, we plan to continue updating the
>> Editor's Draft, and in the next few weeks we expect to post a Call for
>> Consensus to publish it as the First Public Working Draft of HTML5.2, so
>> improving HTML will continue without a pause. It also means that changes
>> that didn't make it into
>> HTML5.1 will not have long to wait before being incorporated into the
>> specification.
>>
>> Léonie on behalf of the WP chairs and team, and HTML editors.
>> [1] https://www.w3.org/TR/html51/
>> [2] https://www.w3.org/TR/html51/changes.html#changes
>> [3] https://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Exclusion
>>
>> [issue 43] https://github.com/w3c/html/issues/43
>> [issue 109] https://github.com/w3c/html/issues/109
>> [issues 159/375/422] https://github.com/w3c/html/issues/159 and links
>> [issue
>> 233] https://github.com/w3c/html/issues/233
>> [issue 269] https://github.com/w3c/html/issues/269
>> [issue 372] https://github.com/w3c/html/issues/372
>> [issue 373] https://github.com/w3c/html/issues/373
>> [issue 427] https://github.com/w3c/html/issues/427
>> [Issue 461] https://github.com/w3c/html/issues/461
>> [Issue 462] https://github.com/w3c/html/issues/462
>>
>>
>> --
>> @LeonieWatson tink.uk Carpe diem
>>
>>
>>
>>
>

[clipboard][DnD][DataTransfer] custom types and security

[Hallvord Reiar Michaelsen Steen]

Hi public-webapps, or the sub-set of your that are interested in
clipboard and DnD stuff: we've started an interesting thread regarding
DataTransfer, custom types and security here

https://github.com/whatwg/html/issues/1244

and implementor input is especially welcome. Allow me to paste parts
of my last comment, explaining a tricky issue I'd like a wider review
of:

Regarding the custom types: obviously, if we want to enable
interoperability between the same web apps running in different
browser engines, we need to spec a shared clipboard format for custom
data. This implies that other native software will also see a "Web
browser custom data" clipboard entry (by any description after some
bikeshedding) and potentially grow features that start making use of
said "Web browser custom data" on paste/drop.

If this is considered an extremely rare use case we should not cater
for, and custom data on the real OS clipboard is considered too risky,
we can of course spec that the browsers should keep custom data
somewhere internally and augment the DataTransfer object with the
internally stored custom data as if it were on the clipboard on the
next paste (unless the OS clipboard's contents changed meanwhile).
This seems harder to test and harder to get right, but it is a
judgement call.

-Hallvord