[clipboard API] platform integration stuff - in spec or out of scope?

Hi,
so I think the Clipboard API spec is shaping up nicely - but here's the question: what's the most important stuff that's lacking, if anything?

http://dev.w3.org/2006/webapi/clipops/clipops.html

One area in particular that the spec sort of skips around, is platform integration. For example, it says all implementations must support reading and writing text/html content - but what, specifically, does that mean for the various platform clipboard implementations? For example, on Windows, IE has a specific HTML clipboard format where it constructs a full (and AFAIK valid) HTML document, then inserts specific StartFragment and EndFragment HTML comments to mark the beginning/end of the selection, along with some extra meta data that also helps describe the start/end of the content that was actually selected for copying:

https://msdn.microsoft.com/en-us/library/windows/desktop/ms649015%28v=vs.85%29.aspx

To do what the user expects, "supporting" HTML format pasting on Windows therefore requires parsing the data on the clipboard to pull out the meta data and/or special comments, and only put the stuff between StartFragment and EndFragment in the DataTransfer object.

Does the spec need to document such platform implementation details?

If yes, do any of the other "mandatory" types have gotchas like Windows "HTML Format" - on any platform? The mandatory types currently are:

  • text/plain
  • text/uri-list
  • text/csv
  • text/css
  • text/html
  • application/xhtml+xml
  • image/png
  • image/jpg, image/jpeg
  • image/gif
  • image/svg+xml
  • application/xml, text/xml
  • application/javascript
  • application/json
  • application/octet-stream
I don't know what these "map to" on platforms that do not use MIME types to describe clipboard contents. Should this information be dug up and included?

-Hallvord R
Anne van Kesteren | 31 Jan 09:47 2015
Picon

Re: Minimum viable custom elements

On Fri, Jan 30, 2015 at 7:22 PM, Alice Boxhall <aboxhall@...> wrote:
> Sure, that works for this example (which was created in a huge rush at the
> last minute before a talk, like probably 90% of my productive work), but I
> don't believe it wouldn't work for
> http://www.polymer-project.org/components/paper-radio-button/demo.html which
> has a fancy animation for changing states.

That example seems to depend on another proprietary extension:
-webkit-tap-highlight-color. I can't find anything else that would be
responsible for the effect.

> So, I naively ask, what's stopping us from standardising something like
> -webkit-appearance: none?

Someone has to put in the work.

--

-- 
https://annevankesteren.nl/

Ryosuke Niwa | 31 Jan 01:54 2015
Picon

Re: Minimum viable custom elements


On Jan 30, 2015, at 10:22 AM, Alice Boxhall <aboxhall-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org> wrote:

On Fri, Jan 30, 2015 at 8:46 AM, Anne van Kesteren <annevk-6shE6wEKUUpmR6Xm/wNWPw@public.gmane.org> wrote:
On Fri, Jan 30, 2015 at 11:05 AM, Steve Faulkner
<faulkner.steve-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> In this radio and checkbox example (view in chrome)
> https://rawgit.com/alice/web-components-demos/master/index.html
> (which has been referenced several times in this thread, but no one has
> critiqued to my knowledge) all of the above are evident, while at the same
> time appearing to overcome the issue of standard control fugliness

The only way it overcomes that is by relying on a proprietary
extension called -webkit-appearance that is not standardized and does
not work reliably across browsers. Furthermore, it's not at all clear
to me why that example needs custom elements to begin with. If we
assume this proprietary extension exists, we can just do this:

http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3397

Which is much much simpler and requires none of the HTML imports,
shadow tree, and all that script. It's also fully accessible and
backwards compatible to the same extent. And shows that the real
tidbit here is -webkit-appearance and not custom elements at all.

(For identical styling you need to move the background-image line into
a distinct input:checked selector block. I messed up a bit with copy
and pasting.)

Sure, that works for this example (which was created in a huge rush at the last minute before a talk, like probably 90% of my productive work), but I don't believe it wouldn't work for http://www.polymer-project.org/components/paper-radio-button/demo.html which has a fancy animation for changing states.

It doesn’t but how does custom elements solve that problem?  This example doesn’t even seem to use “is” and manually sets ARIA attributes.  Could you clarify exactly which accessibility issues custom elements would solve in this example?

So, I naively ask, what's stopping us from standardising something like -webkit-appearance: none? I think that a bunch of the most common accessibility issues we see today come from people (quite justifiably) re-implementing standard HTML elements in order to get the styling they need - with or without using Custom Elements.

Indeed.  It would be really useful to solve this problem either with a CSS property like -webkit-appearance or decorator.  Perhaps Tantek or Fantasai could enlighten us.

Relevant URLs:

- R. Niwa

bugzilla | 30 Jan 15:27 2015
Picon

[Bug 27931] New: Override 'flex' and 'transform' styling

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27931

            Bug ID: 27931
           Summary: Override 'flex' and 'transform' styling
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Fullscreen
          Assignee: annevk@...
          Reporter: annevk@...
        QA Contact: public-webapps-bugzilla@...
                CC: falken@..., mike@..., philipj@...,
                    public-webapps@..., roc@...,
                    simonp@...

The conclusion from
https://lists.w3.org/Archives/Public/www-style/2014Nov/thread.html#msg287 seems
to be that the rendering section should override 'flex' and 'transform'.
Presumably as follows:

  *|*:not(:root):fullscreen {
    flex:none !important;
    transform:none !important;
  }

If anyone disagrees with this now would be a good time to speak up.

--

-- 
You are receiving this mail because:
You are on the CC list for the bug.

LOUIFI, Bruno | 29 Jan 21:04 2015
Picon

=[xhr]

Hi,

I am really disappointed when I saw in Chrome debugger that the XMLHttpRequest.open() is deprecating the synchronous mode. This is was the worst news I red since I started working on web applications.

I don’t know if you release the negative impacts on our professional applications. We made a huge effort creating applications on the web and also providing JavaScript APIs that behave as Java APIs in order to help developers migrating from java to JavaScript technology.

So please reconsider your decision. Our customers use APIs for their professional business. You don’t have right to break their applications.

Regards,

Bruno Louifi

Senior Software Developer

Yan Zhu | 29 Jan 22:00 2015
Picon

Security use cases for packaging

Hi all, looking over the W3C TAG packaging draft [1], I would like to see security through package signing as
a use case for packaging.

A hypothetical scenario using Google/Yahoo's End to End email encryption project:
1. User goes to https://cryptomail.yahoo.com/app.pack for the first time. The HTTP response header
includes a package signing key for that resource. This key is pinned, like in HPKP, for some max-age. (The
key could also just be included as part of the package.)

2. The browser verifies the signature over app.pack (perhaps as a special signature part in the package
body, as in PGP/MIME) using the pinned key for that resource.
3. The packaged app only runs if signature verification succeeds. Verification using the same pinned key
is enforced for the max-age amount of time whenever the user loads the package in the future.

The context here is that some app authors would like to provide better code integrity guarantees via
signing with an offline key. This can be achieved by writing a browser extension or certain types of
installable apps, but those have various disadvantages (lack of cross-browser compatibility and
dependency on a central "app store", for instance).

More considerations in the github issue I opened: https://github.com/w3ctag/packaging-on-the-web/issues/21

Thoughts?

-Yan

[1] https://w3ctag.github.io/packaging-on-the-web/

Arthur Barstow | 29 Jan 12:57 2015
Picon

CfC: publish Wide Review Draft of Manifest for web application; deadline Feb 5

Marcos is working toward a Candidate Recommendation of "Manifest for web 
application" and before that step, we need to publish a Working Draft 
for "Wide Review" [WR] (a WR Draft is equivalent to a "Last Call" draft 
as defined in the consortium's 2005 Process). As such, this is a Call 
for Consensus to publish a new WR draft of this spec using the 2014 
Process [PD-2014] and the proposed review period is three weeks.

The latest Editor's Draft of the spec is: <http://w3c.github.io/manifest/>.

If you have any comments or concerns about this CfC, please reply by 
February 5 at the latest. Silence will be considered as agreeing with 
the proposal and explicit responses are preferred. If no non-resolvable 
blocking issues are raised, this CfC will be considered as passing and 
we will proceed with the publication.

Assuming this CfC passes, Marcos suggested the following groups be 
explicitly asked to review this spec: CSS WG - in particular, the 
"display mode" media feature, and WebAppSec WG. Please let us know if 
there are other groups we should ask to review the spec.

-Thanks, ArtB

[WR] <http://www.w3.org/2014/Process-20140801/#wide-review>
[PD-2014] <http://www.w3.org/2014/Process-20140801/#rec-advance>

Anne van Kesteren | 29 Jan 11:46 2015
Picon

Custom elements and the HTML parser

I tried to explore the synchronous constructor option a bit more. (See
https://wiki.whatwg.org/wiki/CustomElements for details.)

>From an HTML parser perspective the main problem would be that
elements with a dash would have to go into the same path that is
basically a special case for </script> today. So the performance of
the parser would suffer. It's unclear how much of a hit that would be.

Only </script> causes synchronous invocation of script. Otherwise
script is invoked based on a timer or lack of incoming data from the
network to process. This would change that as elements with a dash
could cause synchronous invocation of script as well.

This would give custom elements the same freedom as builtin elements.
We could even add a hook for popping of the end tag so you can emulate
the behavior of these elements: script, style, object, video, and
audio. I don't think there's a way to do that with the alternative
strategies.

(I checked and Servo has no plans to parallelize tree building.)

--

-- 
https://annevankesteren.nl/

bugzilla | 28 Jan 08:00 2015
Picon

[Bug 27915] New: Clients of WebSockets are not NTP synced (and there is no NTP-alike spec)

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27915

            Bug ID: 27915
           Summary: Clients of WebSockets are not NTP synced (and there is
                    no NTP-alike spec)
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: WebSocket API (editor: Ian Hickson)
          Assignee: ian@...
          Reporter: cmartensms@...
        QA Contact: public-webapps-bugzilla@...
                CC: mike@..., public-webapps@...

All major browsers (Chromium, Opera, Firefox, IE) have problems when being used
in realtime networking applications.

Date.now() inside the browser is not synced with NTP, therefore clients can
gain access to systems when they reset their clock to a previous date when
WebRTC or WebSockets are used peer-to-peer.

I think we need desperately a WebSocket extensions spec that can be implemented
in order to sync the network connection with a heartbeat and tick(-ack).

>From a developer perspective, I can't believe nobody had the issue before.
There are also no libraries available, which seems surreal as there are
thousands of users of Socket.IO and other WebSocket libraries where all the
libraries depend on a synced clock as they are using Date.now() etc.

My questions so far are:
- Why are browsers not synced with NTP in the background?
- Why is there no WebSocket extension spec that implements an NTP-like
behaviour?
- How to overwrite the behaviour of Date.now(), it is pretty much bad approach
to do so?

--

-- 
You are receiving this mail because:
You are on the CC list for the bug.

bugzilla | 28 Jan 02:49 2015
Picon

[Bug 27914] New: [Custom]: Typo instantation ---> instantiation

https://www.w3.org/Bugs/Public/show_bug.cgi?id=27914

            Bug ID: 27914
           Summary: [Custom]: Typo instantation ---> instantiation
           Product: WebAppsWG
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Component Model
          Assignee: dglazkov@...
          Reporter: jeffr@...
        QA Contact: public-webapps-bugzilla@...
                CC: mike@..., public-webapps@...
            Blocks: 14968

"instantation" looks like a typo -- "instantiation" likely intended.

--

-- 
You are receiving this mail because:
You are on the CC list for the bug.

chaals | 26 Jan 18:47 2015
Picon

Fwd: Getting to Zaragoza (may be harder)


-------- Beginning of forwarded message  --------
26.01.2015, 20:47, "chaals@..." <chaals@...>:

Hi,

TL;DR: May be harder to get a train, will probably be more expensive than I said.

I've been looking at the renfe site recently. There may or may not be trains, or fewer trains, doing the
direct trip. It's a somewhat unreliable site with regard to available options (although if you get a
ticket you can rely on it). I have been looking for clarification, but thought it would be better to
announce the issues now.

It seems that the cheap prices I had found and quoted have disappeared, so expect something more like €35 -
€75 each way.

There are also buses, which go direct from Madrid airport, or from Barcelona Nord* Bus station, about every
2 hours. They cost less than €20, but take about 3 1/2 hours. http://www.alsa.es (there is a button with
an english flag to switch to english, among the headers and banners at the top of the page).

Barcelona Nord is not the airport, it's by the Metro station "Arc de Triomf". Some buses are "Supra" - bigger
seats (but fewer on the Bus), sort of a business class bus.

If this makes you change your mind, please note it in the voting system...

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@... - - - Find more at http://yandex.com
-------- End of forwarded message --------

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@... - - - Find more at http://yandex.com


Gmane