Re: First Draft of W3C version of URL Spec
On 2014-08-28 18:04, Ian Hickson wrote: On Wed, 27 Aug 2014, Daniel Appelquist wrote: As you might know, the new charter for webapps includes a new version of the URL spec. I am acting as editor of this spec. What's the purpose of the W3C republishing this spec? W3C-specific note: This specification documents current RFC 3986 and RFC 3987 handling in contemporary Web browser implementations. As a consequence, this specification is not compatible with those RFCs. It is published for the purpose of providing a stable reference for the HTML5 specification and reflecting current Web browser HTML5 implementations. The W3C Technical Architecture Group expects to continue the work on the URL specification and produce a future version that will attempt to re-align the URL specification with an updated version of RFC 3986 while preserving interoperability. Best regards, Julian
Re: [Custom] Custom elements and ARIA
On Thu, 28 Aug 2014 16:57:00 +0200, Domenic Denicola dome...@domenicdenicola.com wrote: Hi Steve, thanks greatly for your help. It's clear now that I should have reached out to you for your expertise directly before being very wrong on a public mailing list :) From: Steve Faulkner faulkner.st...@gmail.com It appears (please correct me) you have made the assumption that 'strong native semantics' for roles is a UA requirement? This is not the case (in the W3C HTML spec [1] at least, can't speak for where the WHATWG spec has gone in defining ARIA in HTML), they are author conformance requirements. Yes, I was misled about that pretty badly. That changes things, as it means there are no non-overridable roles or stoperties (as you show with hr role=menuitem). States and properties can be non-overridable, though, as I understand it. [[ When a host language declares a WAI-ARIA [state/property] attribute to be in direct semantic conflict with a native attribute for a given element, user agents MUST ignore the WAI-ARIA attribute and instead use the host language attribute with the same implicit semantic. ]] http://www.w3.org/TR/wai-aria/host_languages#host_general_conflict_header From my reading though, the default implicit ARIA semantics are still UA requirements, right? Yes. [...] -- Simon Pieters Opera Software
[Bug 25313] Improve and add examples
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25313 Mounir Lamouri mou...@lamouri.fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Mounir Lamouri mou...@lamouri.fr --- https://github.com/w3c/screen-orientation/pull/63 -- You are receiving this mail because: You are on the CC list for the bug.
Re: [Custom] Custom elements and ARIA
Hi Domenic, -- Regards SteveF HTML 5.1 http://www.w3.org/html/wg/drafts/html/master/ On 28 August 2014 15:57, Domenic Denicola dome...@domenicdenicola.com wrote: Hi Steve, thanks greatly for your help. It's clear now that I should have reached out to you for your expertise directly before being very wrong on a public mailing list :) don't worry same thing happens to me all the time. From: Steve Faulkner faulkner.st...@gmail.com It appears (please correct me) you have made the assumption that 'strong native semantics' for roles is a UA requirement? This is not the case (in the W3C HTML spec [1] at least, can't speak for where the WHATWG spec has gone in defining ARIA in HTML), they are author conformance requirements. Yes, I was misled about that pretty badly. That changes things, as it means there are no non-overridable roles or stoperties (as you show with hr role=menuitem). For roles this is true, for states and properties native wins where specified (as Simon pointed out) From my reading though, the default implicit ARIA semantics are still UA requirements, right? yes, these are what i pulled out of the spec and tested for HTML CR: http://stevefaulkner.github.io/html-mapping-tests/ This doc lists all the (ARIA section) UA requirements from the HTML5 CR spec, testing results for the 4 major browsers, and browser bugs filed where needed. To be clear, my concern is entirely about UA requirements, so anything authoring-related is irrelevant to me. The HTML spec (any brand) does not define how HTML features map to platform accessibility APIs. This is being normatively defined in the HTML Accessibility API Mappings specification [2]. Would it be worth considering exposing the platform accessibility APIs used in the browser, to JS so that custom elements can be implemented to fully reflect native element accessibility implementations? zcorpan pointed out this strategy in IRC as well. I think it is worth exploring. Although, I was hoping to use ARIA as a platform-independent interface into native platform accessibility APIs; that is, I was assuming that everything a native or custom element would want to do could be expressed with ARIA. But, you state earlier in your message that: I don't think it is currently possible to define the browser accessibility API mappings in terms of ARIA as it defines and incomplete set of roles,states and properties used in acc APIs. This seems unfortunate. Why is that? Could you give an example? I guess because ARIA is not trying to be provide a general abstraction of all roles,states and properties. The only cases (generally) where native features express role/state/property values in terms of ARIA in the acc APIs are where no platform acc API role/state/property exists. IA2 has a caption role that FF maps to the figcaption element, ARIA does not. Would it be more fruitful to augment ARIA in some way, instead of trying to bypass it and go directly to platform accessibility APIs? The latter seems like it would require a platform-agnostic intermediate layer to be defined, which feels redundant with ARIA... Possibly, I would suggest pinging the PF mailing list with some ideas would be a good place to start http://lists.w3.org/Archives/Public/public-pfwg/ HTH
Re: First Draft of W3C version of URL Spec
On Fri, Aug 29, 2014 at 8:11 AM, Julian Reschke julian.resc...@gmx.de wrote: W3C-specific note: This specification documents current RFC 3986 and RFC 3987 handling in contemporary Web browser implementations. As a consequence, this specification is not compatible with those RFCs. It is published for the purpose of providing a stable reference for the HTML5 specification and reflecting current Web browser HTML5 implementations. The W3C Technical Architecture Group expects to continue the work on the URL specification and produce a future version that will attempt to re-align the URL specification with an updated version of RFC 3986 while preserving interoperability. That's a contradictory goal. Anyway, if W3C actually wanted to help here they would focus on getting implementations aligned with the specification before starting to fork and seed confusion. That's the biggest problem for the web at the moment when it comes to URLs.
Re: First Draft of W3C version of URL Spec
On Fri, 2014-08-29 at 21:04 +0200, Anne van Kesteren wrote: On Fri, Aug 29, 2014 at 8:11 AM, Julian Reschke julian.resc...@gmx.de wrote: W3C-specific note: This specification documents current RFC 3986 and RFC 3987 handling in contemporary Web browser implementations. As a consequence, this specification is not compatible with those RFCs. It is published for the purpose of providing a stable reference for the HTML5 specification and reflecting current Web browser HTML5 implementations. The W3C Technical Architecture Group expects to continue the work on the URL specification and produce a future version that will attempt to re-align the URL specification with an updated version of RFC 3986 while preserving interoperability. That's a contradictory goal. Anyway, if W3C actually wanted to help here they would focus on getting implementations aligned with the specification before starting to fork and seed confusion. That's the biggest problem for the web at the moment when it comes to URLs. I would qualify it as ambitious, rather than contradictory. :) Re-aligning the URL specification with RFC3986.next will take time and a lot of effort, especially with the intent of preserving interoperability. And yes, for the immediate short term, the focus is on aligning the Web implementations with the specification as much as we can. Philippe
RE: IE - Security error with new Worker(URL.createObjectURL(new Blob([workerjs],{type:'text/javascript'})))
Just a quick followup: this bug fix has been shipped in our recent Windows
Phone 8.1 update [1]. It will come to a Desktop browser near you soon.
[1]
http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web-should-just-work-for-everyone.aspx
-Original Message-
From: Travis Leithead
Sent: Tuesday, June 10, 2014 5:54 PM
To: Aymeric Vitte; Web Applications Working Group WG (public-webapps@w3.org)
Cc: Adrian Bateman
Subject: RE: IE - Security error with new Worker(URL.createObjectURL(new
Blob([workerjs],{type:'text/javascript'})))
Unfortunately, there is not presently a way for you to track it externally. :-(
MS Connect is the best we have so far, and I know that it is not great. We
recognize this is a problem and hope to be able to improve the situation soon.
-Original Message-
From: Aymeric Vitte [mailto:vitteayme...@gmail.com]
Sent: Tuesday, June 10, 2014 3:00 AM
To: Travis Leithead; Web Applications Working Group WG (public-webapps@w3.org)
Subject: Re: IE - Security error with new Worker(URL.createObjectURL(new
Blob([workerjs],{type:'text/javascript'})))
Thanks, any way to track/be notified when this will be available?
Regards
Aymeric
Le 06/06/2014 19:42, Travis Leithead a écrit :
Well, in IE's defense, this is not specifically allowed by:
http://www.w3.org/TR/workers/#dom-worker. Regardless, the product team is
working to fix this so that it works in IE as well. Stay tuned. I updated the
Connect bug below.
-Original Message-
From: Aymeric Vitte [mailto:vitteayme...@gmail.com]
Sent: Friday, June 6, 2014 6:25 AM
To: Web Applications Working Group WG (public-webapps@w3.org)
Cc: Travis Leithead
Subject: IE - Security error with new Worker(URL.createObjectURL(new
Blob([workerjs],{type:'text/javascript'})))
Why IE(11) does not allow this while this is working on FF and Chrome?
[1] seems to suggest that it is by design.
Regards
Aymeric
[1]
https://connect.microsoft.com/IE/feedback/details/779379/unable-to-spawn-worker-from-blob-url
--
Peersm : http://www.peersm.com
node-Tor : https://www.github.com/Ayms/node-Tor
GitHub : https://www.github.com/Ayms
