Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
I am all for accessibility! But isn't the idea to keep content out of CSS so
that it does not interfere with accessibility as much as possible?
The main problem with the 'content' property is that it is not accessible. Why
I really think it should not be used for more than symbols. ARIA and class
names on the element can help screen readers to make the styling accessible as
needed.
Do you have use cases where unaccessible CSS is actually a problem? And which
actually needs to be done in CSS?
Also, did you speak with people from screen reader software and societies for
people with different needs and preferences? Are they willing to adapt this
feature and on board?
This discussion should probably also move to the W3C mailing list www-style
unless you don't plan to expose it to the web.
Greetings,
Dirk
On Oct 1, 2013, at 7:08 AM, James Craig jcr...@apple.com wrote:
AX: Implement CSS -webkit-alt property
https://bugs.webkit.org/show_bug.cgi?id=120188
This is blocking 20+ bugs on one of our higher profile content sites and we’d
like to start work on it. To clarify, the problem is that with CSS generated
content in pseudo-elements like this:
.expandable::before { content: \25BA; /* a.k.a. ► */ }
…there is no way to prevent VoiceOver from speaking the literal character
description, “right pointing black pointer.” If this were an actual DOM node,
we could hang some ARIA attributes on it, but there is no node for
pseudo-elements, so the property has to be defined in CSS.
The CSS Working Group discussion indicates the editors (Tab from Google, and
Elika from Mozilla) are generally on board with the concept of accessible
text alternatives for CSS generated content and Tab suggested the property
name. It is not in a CSS4 draft yet, but some usage examples are below.
Rendering a decorative disclosure triangle on a collapsed” ARIA treeitem:
[aria-expanded=false”]::before {
content: \25BA; /* a.k.a. ► , literally “right pointing black
pointer” */
alt: ; /* aria-expanded=false already in DOM, so this
pseudo-element is decorative */
}
And this, where a style indicates new content, screen readers can speak “New”
instead of “shadowed white star”:
[data-new]::after {
content: \2730”; /* a.k.a. ✰ , literally “shadowed white star”
*/
alt: attr(data-new); /* allows for localized content from the
DOM, e.g. @data-new=New! */
}
Any questions or concerns?
Thanks,
James
PS. Related to this one is bug 122138, where the “alt” can be specified
inline after url() image content:
AX: WebKit does not expose text alternative of CSS generated image content
https://bugs.webkit.org/show_bug.cgi?id=122138
.new::after {
content: url(./star.png), New!;
}
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] 答复: Proposal: Use ICU in WebKit code
Hi, our internal project is using WinCE port(near 2012-08 code edition) The WinCE port default is NOT supporting ICU, because icu can't compile on WinCE 6.0 (which is ARM little-endian, and use VS2008's crossing-compiler) So it can not take link-break and word-break other than English words. But we have successfully compiled ICU-4.0.1 based on a patch at https://ssl. icu-project.org/trac/attachment/ticket/9561/0001-Enable-Windows-CE-support.p atch So it is possible to use ICU on WinCE port. The ICU cross-compiling is really very disgusting and weird~! -邮件原件- 发件人: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] 代表 Darin Adler 发送时间: 2013年10月5日 15:10 收件人: Dirk Schulze 抄送: WebKit Development 主题: Re: [webkit-dev] Proposal: Use ICU in WebKit code On Oct 4, 2013, at 11:48 PM, Dirk Schulze dschu...@adobe.com wrote: On Oct 5, 2013, at 7:37 AM, Darin Adler da...@apple.com wrote: Any thoughts on this? I am not sure what the status of the WinCE port is, but I’d like to hear from the maintainers of that port on the port status and their view on this strategy. Do you really mean WinCE or WinCairo? I thought that WinCE was discontinued a long time ago and already removed. Probably I was wrong. I don’t know. Let me word the question differently: Is anyone using UnciodeWchar.h/cpp for their port? If so, please respond on this thread. ― Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Use ICU in WebKit code
On 05.10.2013, at 19:13, Brent Fulgham wrote: The WinCairo port is as close to the AppleWin port as possible. It uses ICU and I have no intention of changing that. The WinCE port is maintained by Patrick Gangsterer. I believe that this port does not want to use ICU, preferring to use the limited subset of i18n features provided by the operating system. That's correct, but I think that changing the current API to ICU and implement some stub functions instead is a good idea. Can we put the source code of this dummy-ICU somewhere into the tree? See also the discussion about a reduced ICU at [1], but this would require a big copy of the ICU code in the tree, which I don't see as a good idea. I have heard from a number of people, mainly using WebKit in resource constrained environments, who prefer to omit ICU due to its relatively large footprint. But many of their concerns about library size might be satisfied by rebuilding ICU with settings that omit the large encoding database. This makes sense if their use cases do not need these features. If you use WebKit e.g. as a simple english-only GUI without text-input there is no need for ICU, expect to compile the remaining code. So a dummy-ICU would be everything you need for this use-case and reduces the required resources -Brent Sent from my iPad On Oct 4, 2013, at 11:48 PM, Dirk Schulze dschu...@adobe.com wrote: On Oct 5, 2013, at 7:37 AM, Darin Adler da...@apple.com wrote: Any thoughts on this? I am not sure what the status of the WinCE port is, but I’d like to hear from the maintainers of that port on the port status and their view on this strategy. Do you really mean WinCE or WinCairo? I thought that WinCE was discontinued a long time ago and already removed. Probably I was wrong. Greetings, Dirk -- Patrick [1] https://lists.webkit.org/pipermail/webkit-dev/2013-June/025018.html ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] GCC version consistency on EFL bots?
Hello, We finished to upgrade EFL 32bit buildbot to Ubuntu 13.04. I will try that all EFL bots have same gcc version. Thanks, Gyuyoung. On Mon, Oct 7, 2013 at 12:33 PM, Gyuyoung Kim gyuyoung@webkit.orgwrote: Hello Karen, Thank you for good information. However, as Andreas said, it is important to have the same compiler version both on EWS and bots. So, I feel I need that the problem bot has the same gcc version as soon as possible. Because I don't want to do something against WebKit(or common) development trend and policy. Thanks, Gyuyoung. On Mon, Oct 7, 2013 at 11:35 AM, Karen Shaeffer shaef...@neuralscape.comwrote: Hi Gyuyoung, Be aware: Ubuntu 12.10 (gnu 4.7.2) expires April 2014. Ubuntu 13.04 (gnu 4.7.3) expires Jan 2014. Ubunut 13.10 (gnu 4.8.1) scheduled release date Oct 17 2013. End of life Jul 2014. Ubuntu 14.04 (gnu 4.8.x) scheduled release date Apr 17 2014. LTS release I would avoid 13.04, because you'll need to upgrade twice more within months to get to 14.04 LTS. Either 12.10 or 13.10 allow you only 1 more upgrade to get to 14.04 LTS. I guess the decision should be which compiler version you prefer. enjoy, Karen -- Karen Shaeffer Be aware: If you see an obstacle in your path, Neuralscape Services that obstacle is your path.Zen proverb On Mon, Oct 07, 2013 at 10:26:22AM +0900, Gyuyoung Kim wrote: Hi Andreas, Ah, I only talked on EFL ews bots. Yes, we're running an ubuntu 32bit machine only for a 32bit buildbot. And, it is based on Ubuntu 12.04 and has gcc 4.6.3 version. I think the 32bit buildbot needs to be upgraded. I will do it. Thanks, Gyuyoung. On Mon, Oct 7, 2013 at 10:07 AM, Andreas Kling akl...@apple.com wrote: Hi Gyuyoung, Then why is final/override working on EWS but not on the main build bots? Are they using different compiler flags? According to wtf/Compiler.h, GCC should support override control since at least 4.7.0. Errors here: http://build.webkit.org/builders/EFL%20Linux%2032-bit%20Release%20%28Build%29/builds/22628/steps/compile-webkit/logs/stdio /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:142:60: error: expected ';' at end of member declaration /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:142:62: error: 'override' does not name a type /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:143:87: error: expected ';' at end of member declaration /mnt/buildbot/efl-linux-slave-3/efl-linux-32-release/build/Source/WebCore/editing/markup.cpp:143:89: error: 'override' does not name a type -Andreas On Oct 7, 2013, at 2:01 AM, Gyuyoung Kim gyuyoung@webkit.org wrote: Hi Andreas, Are the main/EWS bots running different versions of GCC? No, EFL ews bots have same gcc version. EFL ews and buildbots are being ran on two machines. As far as I know, those are based on Ubuntu 13.04 and have same gcc 4.7.3. Thanks, Gyuyoung. On Mon, Oct 7, 2013 at 4:56 AM, Andreas Kling akl...@apple.com wrote: Hi folks, I recently landed a patch that makes use of lowercased “override” and “final” in WebKit, and now the EFL build is failing. The EFL EWS bots didn’t have any problem with the patch however, which brings me to my question: Are the main/EWS bots running different versions of GCC? And if so, how soon can we make them use the same one? -Kling ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev --- end quoted text --- ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Status of the Blackberry port
Yes, it's still being maintained by the folks here at BlackBerry. Eli On 13-10-05 7:12 PM, Sam Weinig wei...@apple.com wrote: Hello, Can anyone comment on the status of the Blackberry port? Is it still being maintained? -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev - This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Use ICU in WebKit code
On Oct 7, 2013, at 1:34 AM, Patrick Gansterer par...@paroga.com wrote: On 05.10.2013, at 19:13, Brent Fulgham wrote: The WinCairo port is as close to the AppleWin port as possible. It uses ICU and I have no intention of changing that. The WinCE port is maintained by Patrick Gangsterer. I believe that this port does not want to use ICU, preferring to use the limited subset of i18n features provided by the operating system. That's correct, but I think that changing the current API to ICU and implement some stub functions instead is a good idea. Can we put the source code of this dummy-ICU somewhere into the tree? Sure, seems fine to have it in the WebKit tree, presumably alongside or inside WTF. It’s really the same thing as what’s in wtf/unicode right now with some different function names. Mostly it would be moving that code inside functions with new names. What we need is a road map. I know how to change WebKit to use ICU directly, and how to test that both on my own Mac and the EWS and buildbot machines, but I don’t know how to test and figure out exactly how many of these stub functions are needed, even for a port with a buildbot but especially for one without. Patrick, to state the obvious, if it really is only the WinCE port that would this, then I think it’s a project we need your help on. — Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Please install shellwords on the bots
It appears that Shellwords is part of the standard Ruby install we use on the Cygwin-based Windows systems. -Brent On Oct 6, 2013, at 2:06 PM, Filip Pizlo fpi...@apple.com wrote: On Oct 6, 2013, at 2:00 PM, Benjamin Poulain benja...@webkit.org wrote: On 10/6/13, 1:54 PM, Filip Pizlo wrote: This bug: https://bugs.webkit.org/show_bug.cgi?id=120696 Is for making run-javascriptcore-tests run all of the tests in parallel and in a way that is aware of our multiple tiers. It vastly improves JSC test coverage. Right now, the script will refuse to do anything if your machine doesn't have the Ruby shellwords package installed. Eventually I'll change that to make it just fail. Please install shellwords on the bots so that this script can work. (And no, I don't see an easy alternative to using shellwords for this testing infrastructure. It would take a lot more code if we didn't want to use shellwords. So, you should install shellwords to run javascriptcore tests. It's already installed by default on a lot of OS's.) I'll be landing this patch soon. We need the test coverage. Could run-javascriptcore-tests just install shellwords when it is missing? Probably. There is a precedent of this, webkit-patch downloads every missing packages, making it easy to use without installing the dependencies. In the case of shellwords, the majority of WebKit developers will already have it. It’s part of the Ruby standard library as of version 2. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] JavaScript Stack Changes
We have been making changes to the JavaScript native stack layout in order to align the layout more closely with native C/C++ stack layout. This is being done as part of integrating LLVM as a back-end for the FTL JIT. This is being tracked with the umbrella bug https://bugs.webkit.org/show_bug.cgi?id=116888. We have already changed the stack direction from growing up in address to growing down. We are in the process of changing calls from JavaScript to C helpers to be compliant with native calling conventions by changing calls using JITStubCall.h to use CCallHelpers.h (tracked with https://bugs.webkit.org/show_bug.cgi?id=122287). Other tasks that remain are to rearrange the layout of JSStack so that the CallerFrame and ReturnPC frame location are consistent with native C stack conventions, using the native stack pointer register instead of reserving our own register, and modifying the thunks used to invoke JavaScript from C/C++ code. The JavaScript team at Apple will make and test the changes to support X86 and X86_64 for Mac OS X and Windows, and ARM Thumb 2. We will likely make speculative changes for the other ports (ARM Traditional, MIPS and SH4), but have no means to test those changes. If you maintain the processor specific JavaScript code for one of those ports, send me a reply so we can coordinate changes to minimize breakage. - Michael Saboff ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] [WinCairo] : is ACCELERATED COMPOSITING under progress ?
Expecting ACCELERATED_COMPOSITING along with WinCairo, I noticed come conflicts raised by building WebKit over MsDev 2010. Looks like ACCELERATED_COMPOSITING is sort of wired to CoreAnimation (and CoreGraphics). So is there any plan to make WinCairo sensitive to HW acceleration ? Regardless of Corexxx stuff... ? ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] [WinCairo] : is ACCELERATED COMPOSITING under progress ?
On Oct 7, 2013, at 11:32 AM, Urbain EGIS urbain.e...@gmail.com wrote: Expecting ACCELERATED_COMPOSITING along with WinCairo, I noticed come conflicts raised by building WebKit over MsDev 2010. Looks like ACCELERATED_COMPOSITING is sort of wired to CoreAnimation (and CoreGraphics). So is there any plan to make WinCairo sensitive to HW acceleration ? Regardless of Corexxx stuff… ? Yes. This will be based on the Texture Mapper code, which is partially working under WinCairo. But work is stalled at the moment due to time constraints. -Brent ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] AX: Implement CSS -webkit-alt property (text alternative for generated content pseudo-elements ::before and ::after)
Hi Dirk,
On Oct 7, 2013, at 12:36 AM, Dirk Schulze dschu...@adobe.com wrote:
I am all for accessibility! But isn't the idea to keep content out of CSS so
that it does not interfere with accessibility as much as possible?
The main problem with the 'content' property is that it is not accessible.
Why I really think it should not be used for more than symbols. ARIA and
class names on the element can help screen readers to make the styling
accessible as needed.
Is this a question? I'm not sure what you're driving at. Yes ARIA can be used
to provide labels, but when CSS content is used, there's nothing to label (ie
DOM Node)
Do you have use cases where unaccessible CSS is actually a problem? And
which actually needs to be done in CSS?
We come across scenarios like
[data-new]::after {
content: \2730”; /* a.k.a. ✰ , literally “shadowed white star”
*/
alt: attr(data-new); /* allows for localized content from the
DOM, e.g. @data-new=New! */
}
Where we don't want the screen reader to say shadowed white star -- we want
to label it with the semantic description -- New!
Also, did you speak with people from screen reader software and societies for
people with different needs and preferences? Are they willing to adapt this
feature and on board?
Apple makes a screen reader for Mac and iOS, so this is not an issue for us.
Moreover, there's nothing for them to adapt or be on board with. WebKit can
start vending the right information and everyone benefits.
This discussion should probably also move to the W3C mailing list www-style
unless you don't plan to expose it to the web.
Inside the webkit bug, the first comment states:
Description From James Craig 2013-08-22 17:59:42 PST (-) [reply]
AX: Implement CSS -webkit-alt property
Not in a spec yet, but discussion was positive and the issue is being tracked
by the CSS WG. Since this is holding up several projects, I propose
implementing the vendor-prefixed form: -webkit-alt.
http://lists.w3.org/Archives/Public/www-style/2012Nov/0319.html
Greetings,
Dirk
On Oct 1, 2013, at 7:08 AM, James Craig jcr...@apple.com wrote:
AX: Implement CSS -webkit-alt property
https://bugs.webkit.org/show_bug.cgi?id=120188
This is blocking 20+ bugs on one of our higher profile content sites and
we’d like to start work on it. To clarify, the problem is that with CSS
generated content in pseudo-elements like this:
.expandable::before { content: \25BA; /* a.k.a. ► */ }
…there is no way to prevent VoiceOver from speaking the literal character
description, “right pointing black pointer.” If this were an actual DOM
node, we could hang some ARIA attributes on it, but there is no node for
pseudo-elements, so the property has to be defined in CSS.
The CSS Working Group discussion indicates the editors (Tab from Google, and
Elika from Mozilla) are generally on board with the concept of accessible
text alternatives for CSS generated content and Tab suggested the property
name. It is not in a CSS4 draft yet, but some usage examples are below.
Rendering a decorative disclosure triangle on a collapsed” ARIA treeitem:
[aria-expanded=false”]::before {
content: \25BA; /* a.k.a. ► , literally “right pointing black
pointer” */
alt: ; /* aria-expanded=false already in DOM, so this
pseudo-element is decorative */
}
And this, where a style indicates new content, screen readers can speak
“New” instead of “shadowed white star”:
[data-new]::after {
content: \2730”; /* a.k.a. ✰ , literally “shadowed white star”
*/
alt: attr(data-new); /* allows for localized content from the
DOM, e.g. @data-new=New! */
}
Any questions or concerns?
Thanks,
James
PS. Related to this one is bug 122138, where the “alt” can be specified
inline after url() image content:
AX: WebKit does not expose text alternative of CSS generated image content
https://bugs.webkit.org/show_bug.cgi?id=122138
.new::after {
content: url(./star.png), New!;
}
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Proposal: Use ICU in WebKit code
On 07.10.2013, at 18:28, Darin Adler wrote: On Oct 7, 2013, at 1:34 AM, Patrick Gansterer par...@paroga.com wrote: On 05.10.2013, at 19:13, Brent Fulgham wrote: The WinCairo port is as close to the AppleWin port as possible. It uses ICU and I have no intention of changing that. The WinCE port is maintained by Patrick Gangsterer. I believe that this port does not want to use ICU, preferring to use the limited subset of i18n features provided by the operating system. That's correct, but I think that changing the current API to ICU and implement some stub functions instead is a good idea. Can we put the source code of this dummy-ICU somewhere into the tree? Sure, seems fine to have it in the WebKit tree, presumably alongside or inside WTF. It’s really the same thing as what’s in wtf/unicode right now with some different function names. Mostly it would be moving that code inside functions with new names. What we need is a road map. I know how to change WebKit to use ICU directly, and how to test that both on my own Mac and the EWS and buildbot machines, but I don’t know how to test and figure out exactly how many of these stub functions are needed, even for a port with a buildbot but especially for one without. Patrick, to state the obvious, if it really is only the WinCE port that would this, then I think it’s a project we need your help on. I'd suggest that you do your thing by kicking out the WTF-Unicode and replace it by the ICU functions. Maybe you can think about where the dummy functions can live and I'll do the rest. I don't want to block anyone with this, but it would be great if someone feels responsible for reviewing my patches then. :-) -- Patrick ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
