Summary: | CSS property "-webkit-text-size-adjust" means different things in Safari and iOS | ||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | ar <webkitbugs> | ||||||||||||
Component: | CSS | Assignee: | Nobody <webkit-unassigned> | ||||||||||||
Status: | RESOLVED FIXED | ||||||||||||||
Severity: | Normal | CC: | adam-f3-webkit, ahf, allan.jensen, ap, benm, cshu, ddkilzer, dglazkov, eoconnor, eric, esprehn+autocc, gyuyoung.kim, hyatt, jcraig, joepeck, johnme, jreck, kenneth, laszlo.gombos, ljaehun.lim, macpherson, menard, mifenton, mitz, ojan.autocc, parag, rakuco, simon.fraser, solo-webkit, syoichi, tonikitoo, wamatt, webkit.org, webkit.review.bot | ||||||||||||
Priority: | P3 | Keywords: | InRadar, WebExposed | ||||||||||||
Version: | 528+ (Nightly build) | ||||||||||||||
Hardware: | Mac (Intel) | ||||||||||||||
OS: | OS X 10.6 | ||||||||||||||
See Also: | https://bugs.webkit.org/show_bug.cgi?id=259435 | ||||||||||||||
Bug Depends on: | |||||||||||||||
Bug Blocks: | 70342, 73546 | ||||||||||||||
Attachments: |
|
Description
ar
2011-03-16 23:32:06 PDT
text-size-adjust was added in http://trac.webkit.org/changeset/6805 with an -apple prefix. I think this has a different meaning that the iOS -webkit-text-size-adjust. I just realized there's a typo in my Testcase. In the "Workaround #1" sample CSS code, "#wa2" (both of them) should be "#wa1". The typo is *only* in the sample code that you see when you're looking at the rendered page. The actual CSS (in the <head><styles>) that targets/effects that block ("Workaround #1") is correct. I think we should deprecate or rename the version of -webkit-text-size-adjust that was added in r6805. I believe it only has users inside Apple, and we can fix those to use a new name. Created attachment 95643 [details]
Patch to restrict -webkit-text-size-adjust to iOS only
Comment on attachment 95643 [details]
Patch to restrict -webkit-text-size-adjust to iOS only
This will break Safari RSS.
(In reply to comment #6) > (From update of attachment 95643 [details]) > This will break Safari RSS. How so? The RSS reader looks fine with this patch. Cmd +/- doesn't scale the RSS sidebar. The minimum font size setting will now affect the RSS reader, but IMHO that would be fixing the RSS reader not breaking it. Safari RSS and some other Apple-internal content expect -webkit-text-size-adjust to work the old way. We can't change this until that internal content has been updated to use something else. (In reply to comment #7) > (In reply to comment #6) > > (From update of attachment 95643 [details] [details]) > > This will break Safari RSS. > > How so? The RSS reader looks fine with this patch. Cmd +/- doesn't scale the RSS sidebar. Did you test with View > Zoom Text Only enabled? (In reply to comment #9) > (In reply to comment #7) > > (In reply to comment #6) > > > (From update of attachment 95643 [details] [details] [details]) > > > This will break Safari RSS. > > > > How so? The RSS reader looks fine with this patch. Cmd +/- doesn't scale the RSS sidebar. > > Did you test with View > Zoom Text Only enabled? Ah, no, I hadn't. That option does cause the sidebar to scale. So should I change it so that this CSS property is still honored for Safari as well? Are there any other browsers that expect this property to be supported? Could we make supporting this property a configurable option, perhaps at runtime on the Settings object? It could default to true so as to not break existing apps, but platforms like Android that want to provide a different behavior for accessibility can disable it at startup. Or maybe we could do it at compile time with an ENABLE macro or similar. Then it's easy for each platform to make their own choice. We need this support for Qt as well. Created attachment 117877 [details]
Patch
Comment on attachment 117877 [details]
Patch
I think you are misunderstanding. -webkit-text-size-means something totally different on iOS and desktop. It's not just a question of some size threshold. We need to migrate desktop clients to a different property name before adding any mobile-style text size adjust.
(In reply to comment #14) > I think you are misunderstanding. -webkit-text-size-means something totally different on iOS and desktop. It's not just a question of some size threshold. We need to migrate desktop clients to a different property name before adding any mobile-style text size adjust. Do you suggest that we rename the current implementation to something else like -apple-text-size-adjust? Or do you have a better suggestion? (In reply to comment #15) > (In reply to comment #14) > > I think you are misunderstanding. -webkit-text-size-means something totally different on iOS and desktop. It's not just a question of some size threshold. We need to migrate desktop clients to a different property name before adding any mobile-style text size adjust. > > Do you suggest that we rename the current implementation to something else like -apple-text-size-adjust? Or do you have a better suggestion? I think it needs a new name, not just a different prefix. Or there's a chance that it could be removed, but someone inside of Apple would have to verify that. (In reply to comment #16) > I think it needs a new name, not just a different prefix. Or there's a chance that it could be removed, but someone inside of Apple would have to verify that. Thanks for clarifying. Who within Apple should I try to contact regarding this? I'll ask around and get back to you. Any updates to this? It looks like this stalled out. Any updates Edward? Ping. We are really looking forward to get this fixed. Any updates to this? *** Bug 83052 has been marked as a duplicate of this bug. *** From the duplicate: The desktop implementation (preventing users from explicitly enlarging their font size) is in violation of both WCAG Guideline 1.4.4 and UAAG Guideline 4.1. WCAG Guideline 1.4: http://www.w3.org/TR/WCAG/#visual-audio-contrast 1.4.4 Resize text: Except for captions and images of text, text can be resized without assistive technology up to 200 percent without loss of content or functionality. (Level AA) UAAG Guideline 4. Ensure user control of rendering http://www.w3.org/TR/UAAG/guidelines.html#gl-user-control-styles 4.1 Configure text scale (P1) (1) Allow global configuration of the scale of visually rendered text content. Preserve distinctions in the size of rendered text as the user increases or decreases the scale. (2) As part of satisfying provision one of this checkpoint, provide a configuration option to override rendered text sizes specified by the author or user agent defaults Still appears stalled, is anyone taking ownership? Would be great to see it bug squashed, as it appears to have non-trivial user visibility. My plan here is to wrap the CSS code in ENABLE(TEXT_AUTOSIZING), with the assumption that the CSS property will be used at some point in future for text autosizing by non-iOS ports. However, the property would just do nothing until that's hooked up. Is that acceptable? Or would it be better to just remove it? Created attachment 192052 [details]
Remove desktop version of -webkit-text-size-adjust property.
Comment on attachment 192052 [details] Remove desktop version of -webkit-text-size-adjust property. View in context: https://bugs.webkit.org/attachment.cgi?id=192052&action=review > Source/WebCore/css/svg.css:-61 > -text, tspan, tref { > - -webkit-text-size-adjust: none; > -} > - I suggest you file a bug saying that, after this patch, text inside SVG will grow when zoomed. Or reopen http://bugs.webkit.org/show_bug.cgi?id=6487 Created attachment 192060 [details]
Patch for EWS and landing
Comment on attachment 192060 [details] Patch for EWS and landing Attachment 192060 [details] did not pass chromium-ews (chromium-xvfb): Output: http://webkit-commit-queue.appspot.com/results/16987255 New failing tests: html5lib/generated/run-tests16-data.html Comment on attachment 192060 [details] Patch for EWS and landing Clearing flags on attachment: 192060 Committed r145168: <http://trac.webkit.org/changeset/145168> All reviewed patches have been landed. Closing bug. |