Bug 94227

Summary: Text Autosizing: Multiply large fonts less, as they are already more legible.
Product: WebKit Reporter: John Mellor <johnme>
Component: Layout and RenderingAssignee: John Mellor <johnme>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, aelias, bruno.abinader, eric, jchaffraix, kenneth, peter, satish, simon.fraser, tmpsantos, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on:    
Bug Blocks: 84186    
Attachments:
Description Flags
Patch
none
Patch
none
Patch none

John Mellor
Reported 2012-08-16 10:45:29 PDT
Rather than uniformly multiplying font sizes by the multiplier (derived from the width of the block), we should multiply fonts that are already large less, since they are already more legible hence there is less need for them to grow. It is still important to maintain differentiation between text that the author specified to be of different sizes. See discussion in https://bugs.webkit.org/show_bug.cgi?id=91660#c33. I've plotted a graph of some of the available options: http://fooplot.com/plot/61n34syi04 The x axis is specifiedSize, the y axis is computedSize, the blue line is what Chrome for Android uses, the red line is what Firefox for Mobile uses, and the green lines are the two alternative proposals from https://bugzilla.mozilla.org/show_bug.cgi?id=777089. All the lines except the dark green (minimum size + specified size) one eventually join onto y=x. In other words, everyone seems to agree that there's no point increasing the size of text that's already huge. The major difference between Chrome and Firefox is that when specifiedSize is 0, Chrome's computedSize is 0, whereas Firefox's computedSize is the minimum legible font size (computed using something like 13px * multiplier, so 26px if the multiplier is 2 as in the graph). The Chrome approach (disclaimer: I wrote it) seems to make more sense, since if the author chose a tiny font size, they presumably did so deliberately, presumably because that paragraph is less important. I see the role of Text Autosizing as equaling the legibility of a page on desktop (the environment it was probably designed for), but see no particular benefit to forcing all text to be some minimum size. So unless I hear arguments to the contrary, I'll probably go with the Chrome approach, where specifiedSize <= 15px gets multiplied directly by the multiplier, then above that the computedSize grows in proportion to the specifiedSize, but at a rate slower than 1:1, until the computedSize meets the computedSize=specifiedSize line, at which point it just stays on that line.
Attachments
Patch (9.55 KB, patch)
2012-08-17 09:56 PDT, John Mellor 		no flags
DetailsFormatted DiffDiff
Patch (9.44 KB, patch)
2012-08-20 10:29 PDT, John Mellor 		no flags
DetailsFormatted DiffDiff
Patch (9.50 KB, patch)
2012-08-23 04:40 PDT, John Mellor 		no flags
DetailsFormatted DiffDiff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.
Kenneth Rohde Christiansen
Comment 1 2012-08-16 11:53:38 PDT
Nice description. I think a minimum size makes some sense; though I am not arguing for either. Think about it, the point is that it should be possible to read text when zoomed in to just contain the container containing the text, removing the necessity to scroll horizontally (which can be difficult without undeliberately panning away from the container). Without forcing a minimum size there will be cases where you need to zoom further in in order to be able to read the text, which results in required horizontal panning. It might make sense here to consider the landscape mode. Ie. the font needs not be enlarged more than it is possible to read it in landscape mode. Maybe that is a reasonable compromise.
John Mellor
Comment 2 2012-08-17 03:17:25 PDT
(In reply to comment #1) > I think a minimum size makes some sense; though I am not arguing for either. > > Think about it, the point is that it should be possible to read text when zoomed in to just contain the container containing the text, removing the necessity to scroll horizontally (which can be difficult without undeliberately panning away from the container). > > Without forcing a minimum size there will be cases where you need to zoom further in in order to be able to read the text, which results in required horizontal panning. But the author has chosen to make this text illegible (or hard to read) on desktop. Why should we make it more legible on mobile than on desktop? For example, say the author sets the font size of some text to 8 CSS pixels, in a block of text that is 640 CSS pixels wide on a screen that's 320 logical pixels wide. The multiplier will be 640/320=2, so with the Chrome approach we'll set the font size to 16 CSS pixels, but due to the width of the block if they fit the block to the screen they will view it at 50% size due to the zoom, so the effective font size will be 16/2 = 8 CSS pixels, i.e. exactly as legible as it would have been on desktop. > It might make sense here to consider the landscape mode. Ie. the font needs not be enlarged more than it is possible to read it in landscape mode. Maybe that is a reasonable compromise. I think it's most useful to optimize for the orientation the user has chosen to hold the device in. If it's portrait, we multiply sizes more; if it's landscape, we multiply sizes less*. Repeatedly forcing the user to rotate to landscape is not a good user experience. Based on this, I would also recommend recomputing Text Autosizing when the user rotates their device, though if some ports value pretty rotation animations over the ensuing text legibility, then I guess this could be configurable. *: This already works, since TextAutosizer::processBox sets the multiplier inversely proportional to the window width (which is greater in landscape).
Kenneth Rohde Christiansen
Comment 3 2012-08-17 04:31:32 PDT
> For example, say the author sets the font size of some text to 8 CSS pixels, in a block of text that is 640 CSS pixels wide on a screen that's 320 logical pixels wide. The multiplier will be 640/320=2, so with the Chrome approach we'll set the font size to 16 CSS pixels, but due to the width of the block if they fit the block to the screen they will view it at 50% size due to the zoom, so the effective font size will be 16/2 = 8 CSS pixels, i.e. exactly as legible as it would have been on desktop. I am not trying to argue that the other solution is better :-) I just wanted to find some arguments for it. > Based on this, I would also recommend recomputing Text Autosizing when the user rotates their device, though if some ports value pretty rotation animations over the ensuing text legibility, then I guess this could be configurable. I think most people change the orientation as the text is too small and it requires too much effort to read it. Personally I much prefer to just use portrait. If this is indeed the case, it speaks for not treading it differently. Or always look at the actual device width and not current width.
John Mellor
Comment 4 2012-08-17 04:46:06 PDT
(In reply to comment #3) > > Based on this, I would also recommend recomputing Text Autosizing when the user rotates their device, though if some ports value pretty rotation animations over the ensuing text legibility, then I guess this could be configurable. > > I think most people change the orientation as the text is too small and it requires too much effort to read it. Personally I much prefer to just use portrait. If this is indeed the case, it speaks for not treading it differently. Or always look at the actual device width and not current width. Like you I prefer to always use portrait, hence I think we should aim to make the portrait text big enough such that people don't need to change orientation (indeed such that there is no benefit in changing orientation, except to see more words per line). That's how it works in Chrome, Firefox and IE Mobile; it's only in Mobile Safari and the Nokia N9 browser that it's possible for the text to become too small in portrait (due to the various caps and clustering). I'm not quite sure what you mean by actual device width vs current width. If by actual device width you mean always using min(screen width, screen height) rather than using the screen width in the current orientation (which will be larger in landscape), then I disagree. Using the same multiplier in both portrait and landscape would mean that text is either too small in portrait or too large in landscape (or both).
Kenneth Rohde Christiansen
Comment 5 2012-08-17 04:51:08 PDT
> Like you I prefer to always use portrait, hence I think we should aim to make the portrait text big enough such that people don't need to change orientation (indeed such that there is no benefit in changing orientation, except to see more words per line). That's how it works in Chrome, Firefox and IE Mobile; it's only in Mobile Safari and the Nokia N9 browser that it's possible for the text to become too small in portrait (due to the various caps and clustering). > > I'm not quite sure what you mean by actual device width vs current width. If by actual device width you mean always using min(screen width, screen height) rather than using the screen width in the current orientation (which will be larger in landscape), then I disagree. Using the same multiplier in both portrait and landscape would mean that text is either too small in portrait or too large in landscape (or both). I mean, don't change the layout when changing orientation unless the viewport info forces you to. That means everything is just scaled up in landscape (what I believe most people expect) when there are no viewport restrictions. That said, I mean that you calculate the fonts sizes as if you were always in portrait.
John Mellor
Comment 6 2012-08-17 09:56:12 PDT
Created attachment 159145 [details] Patch This implements the algorithm from Chrome for Android, chosen for the reasons described above.
John Mellor
Comment 7 2012-08-17 11:24:24 PDT
(In reply to comment #5) > I mean, don't change the layout when changing orientation unless the viewport info forces you to. That means everything is just scaled up in landscape (what I believe most people expect) when there are no viewport restrictions. That said, I mean that you calculate the fonts sizes as if you were always in portrait. I suspect people's expectations would adapt fairly quickly whichever approach is taken here, so we should probably decide based on which is most useful. On a phone since landscape mode AFAIK isn't much used normally (though people with less nimble fingers are more likely to prefer landscape mode since it's easier to type in), I can imagine it might indeed be useful to get bigger font sizes in landscape as you are suggesting, e.g. in cases where the user hasn't got their glasses, or is bleary-eyed in the morning, or is jogging. On tablet however landscape mode is on a more equal footing with portrait mode, so I feel it would be strange to get different font sizes. It's not clear what's best here. It also has to match how the browser rotates width=device-width viewport sites. Mobile Safari, and possibly Nokia N9 browser, prefer to just stretch the existing layout, whereas other browsers always resize it. Web developers certainly seem to prefer resizing, given the prevalence of width=device-width,initial-scale=1,maximum-scale=1 viewports used to work around this behavior and force Mobile Safari to resize it (with the unfortunate side-effect of preventing user zooming) [1]. Either way, this is orthogonal to the algorithm for mapping specifiedSizes onto computedSizes given a multiplier, so we should probably open a new bug for this :) [1]: http://www.456bereastreet.com/archive/201012/controlling_text_size_in_safari_for_ios_without_disabling_user_zoom/
Kenneth Rohde Christiansen
Comment 8 2012-08-18 13:56:00 PDT
> It's not clear what's best here. It also has to match how the browser rotates width=device-width viewport sites. Mobile Safari, and possibly Nokia N9 browser, prefer to just stretch the existing layout, whereas other browsers always resize it. Yes, for us device-width is the width when holding the device in its preferred orientation, ie for a phone, device-width is the width when holding the phone in portrait mode. Web authors can easily override this by not allowing changing the scale (maximum-scale=1 etc) > Web developers certainly seem to prefer resizing, given the prevalence of width=device-width,initial-scale=1,maximum-scale=1 viewports used to work around this behavior and force Mobile Safari to resize it (with the unfortunate side-effect of preventing user zooming) [1]. Yes, they usually prefer that when making web apps, because apps do that. I believe the other is a better default. The point is that per default the browser tries to show you the exact same area of content when changing orientation. Ie, I could double-tap to zoom into a column, and then change to portrait and I will see the exact same contents (width-wise). This works pretty well for pages not defining a viewport meta tag. It would be good if browsers actually handled this the same way.
John Mellor
Comment 9 2012-08-20 10:26:13 PDT
(In reply to comment #8) > Yes, for us device-width is the width when holding the device in its preferred orientation, ie for a phone, device-width is the width when holding the phone in portrait mode. Web authors can easily override this by not allowing changing the scale (maximum-scale=1 etc) But as noted in comment #7, this has the often undesirable side-effect of preventing the user from zooming in/out (even on width=device-width pages, it can be nice to zoom in, e.g. to fit an image to the screen). > > Web developers certainly seem to prefer resizing, given the prevalence of width=device-width,initial-scale=1,maximum-scale=1 viewports used to work around this behavior and force Mobile Safari to resize it (with the unfortunate side-effect of preventing user zooming) [1]. > > Yes, they usually prefer that when making web apps, because apps do that. I believe the other is a better default. The point is that per default the browser tries to show you the exact same area of content when changing orientation. Ie, I could double-tap to zoom into a column, and then change to portrait and I will see the exact same contents (width-wise). It's not just web apps; most web pages I've seen override it too. It just doesn't make sense for everything to get 80% bigger (e.g. 854/480 = 1.78) in landscape, unless you expect the user to be holding the device almost twice as far away from their eyes, which I doubt. And showing the same content when you change orientation is still possible if you resize the viewport. It may require slightly more work by the browser, but even in the worst case if the layout changes significantly the browser could remember what block was currently centered (and how far through it you have scrolled), and make that block still be centered (and equivalently scrolled) after the orientation change. So all you really lose is the ability to so a perfectly smooth animation where you just rotate the page, which is a small price to pay in exchange for the page being much more usable after the orientation change - after all people spend much longer reading content than they do rotating their devices... > This works pretty well for pages not defining a viewport meta tag. For pages not defining a viewport meta tag this choice doesn't occur, as they'll use the same fixed width (usually 980px) in both orientations. > It would be good if browsers actually handled this the same way. Agreed.
John Mellor
Comment 10 2012-08-20 10:29:47 PDT
Created attachment 159469 [details] Patch Rebased following the changes in bug 91660. The EWS bots should now be able to run this. The patch continues to be mainly orthogonal to the (interesting) discussion in the bug :)
Kenneth Rohde Christiansen
Comment 11 2012-08-21 00:48:11 PDT
(In reply to comment #9) > (In reply to comment #8) > > Yes, for us device-width is the width when holding the device in its preferred orientation, ie for a phone, device-width is the width when holding the phone in portrait mode. Web authors can easily override this by not allowing changing the scale (maximum-scale=1 etc) > > But as noted in comment #7, this has the often undesirable side-effect of preventing the user from zooming in/out (even on width=device-width pages, it can be nice to zoom in, e.g. to fit an image to the screen). But on the other hand, people who want to mimic native apps don't want whole-ui zooming as that is not something that people are used to in native apps. > It's not just web apps; most web pages I've seen override it too. I think many pages override it by mistake as they don't know what they are doing and the viewport meta tag is usually ignored in desktop browsers. > It just doesn't make sense for everything to get 80% bigger (e.g. 854/480 = 1.78) in landscape, unless you expect the user to be holding the device almost twice as far away from their eyes, which I doubt. Think abuot it the other way around. You double tapped to zoom in a column, now you change from landscape to portrait, and you have to readjust the view in order to read the column. You do not need to do that on iOS or the N9. This is especially useful for desktop pages. > And showing the same content when you change orientation is still possible if you resize the viewport. It may require slightly more work by the browser, but even in the worst case if the layout changes significantly the browser could remember what block was currently centered (and how far through it you have scrolled), and make that block still be centered (and equivalently scrolled) after the orientation change. So all you really lose is the ability to so a perfectly smooth animation where you just rotate the page, which is a small price to pay in exchange for the page being much more usable after the orientation change - after all people spend much longer reading content than they do rotating their devices... It is much more complicated to do that for columns that you are zoomed into so that they fit the viewport width. Some columns might also be fixed sized (using images etc which should fix). It can probably be done, but I am afraid that there are so many corner cases which break.
John Mellor
Comment 12 2012-08-21 08:16:22 PDT
(In reply to comment #11) > But on the other hand, people who want to mimic native apps don't want whole-ui zooming as that is not something that people are used to in native apps. Sure - those people can just use user-scalable=no. But there are bunch of well-known web developers who want user-scalable=yes for its accessibility benefits yet dislike the Safari/N9 rotation behaviour: - http://adactio.com/journal/5088/ - https://github.com/scottjehl/Device-Bugs/issues/2 - http://www.456bereastreet.com/archive/201012/controlling_text_size_in_safari_for_ios_without_disabling_user_zoom/ - https://github.com/h5bp/html5-boilerplate/issues/1099 Though according to https://twitter.com/wilto/status/212636063762628608 the Safari bug has been fixed in iOS 6, so it'll be possible to use a "width=device-width, initial-scale=1" viewport without the zoom glitching when you rotate from portrait to landscape. (In case you're wondering, I can't reproduce that exact bug on N9 if I try http://filamentgroup.com/examples/iosScaleBug/, but I do note that on http://jsbin.com/urowoh/44#device-width,scale=1 if you rotate from portrait to landscape you end up excessively zoomed in -- indeed, further than the maximum-scale allows -- which is fairly similar). > > It's not just web apps; most web pages I've seen override it too. > > I think many pages override it by mistake as they don't know what they are doing and the viewport meta tag is usually ignored in desktop browsers. While I agree that there's a lot of blind copy/pasting going on, I think the links above show that knowledgeable page authors also dislike the zooming; meanwhile I've yet to find anyone who actually likes it. > > It just doesn't make sense for everything to get 80% bigger (e.g. 854/480 = 1.78) in landscape, unless you expect the user to be holding the device almost twice as far away from their eyes, which I doubt. > > Think abuot it the other way around. You double tapped to zoom in a column, now you change from landscape to portrait, and you have to readjust the view in order to read the column. You do not need to do that on iOS or the N9. This is especially useful for desktop pages. As I explained the same content can be kept in view (e.g. you can be reading the same column, scrolled the same way down it). > > And showing the same content when you change orientation is still possible if you resize the viewport. It may require slightly more work by the browser, but even in the worst case if the layout changes significantly the browser could remember what block was currently centered (and how far through it you have scrolled), and make that block still be centered (and equivalently scrolled) after the orientation change. So all you really lose is the ability to so a perfectly smooth animation where you just rotate the page, which is a small price to pay in exchange for the page being much more usable after the orientation change - after all people spend much longer reading content than they do rotating their devices... > > It is much more complicated to do that for columns that you are zoomed into so that they fit the viewport width. Some columns might also be fixed sized (using images etc which should fix). It can probably be done, but I am afraid that there are so many corner cases which break. You can guarantee that the content they had centered is still centered. The things surrounding that content may well change (though in practice this is rarely a problem), but that should be "good enough". Hence having a decent but imperfect orientation change animation seems far preferable to sacrificing landscape mode, by making the text excessively large (note that when viewing desktop pages in Mobile Safari and N9 text is often too small in portrait mode, so the increased size in landscape can actually be a benefit; but if text had already been an easily legible size in portrait mode, it would be even larger in landscape mode).
Kenneth Rohde Christiansen
Comment 13 2012-08-21 09:24:13 PDT
(In reply to comment #12) > (In reply to comment #11) > > But on the other hand, people who want to mimic native apps don't want whole-ui zooming as that is not something that people are used to in native apps. > > Sure - those people can just use user-scalable=no. But there are bunch of well-known web developers who want user-scalable=yes for its accessibility benefits yet dislike the Safari/N9 rotation behaviour: > > - http://adactio.com/journal/5088/ > - https://github.com/scottjehl/Device-Bugs/issues/2 > - http://www.456bereastreet.com/archive/201012/controlling_text_size_in_safari_for_ios_without_disabling_user_zoom/ > - https://github.com/h5bp/html5-boilerplate/issues/1099 > > Though according to https://twitter.com/wilto/status/212636063762628608 the Safari bug has been fixed in iOS 6, so it'll be possible to use a "width=device-width, initial-scale=1" viewport without the zoom glitching when you rotate from portrait to landscape. > > (In case you're wondering, I can't reproduce that exact bug on N9 if I try http://filamentgroup.com/examples/iosScaleBug/, but I do note that on http://jsbin.com/urowoh/44#device-width,scale=1 if you rotate from portrait to landscape you end up excessively zoomed in -- indeed, further than the maximum-scale allows -- which is fairly similar). Yes, it might seem as a bug, but I am pretty confident that it was designed this way. But I do agree that people want to have zooming allowed and still not having it auto adjust. That is a pretty valid use-case. It is pretty interesting that they changed this for the latest iOS. Do you have access to that? I am interested if they disable that for pages using the viewport meta tag or generally, or when using initial-scale? > > > It's not just web apps; most web pages I've seen override it too. > > > > I think many pages override it by mistake as they don't know what they are doing and the viewport meta tag is usually ignored in desktop browsers. > > While I agree that there's a lot of blind copy/pasting going on, I think the links above show that knowledgeable page authors also dislike the zooming; meanwhile I've yet to find anyone who actually likes it. I actually like it :-) I guess people who like it don't speak up as much as those two dislike it :-) Anyway, I like that I can read something in landscape, rotate and still read it without having to do additional zooming. I agree that this is most useful for desktop pages with columns. I am most interesting in how iOS "solved" this. Because it would be best to standardize this in the spec. > As I explained the same content can be kept in view (e.g. you can be reading the same column, scrolled the same way down it). But then you might still need to change the scale to fit the width into the smaller viewport width (going from landscape to portrait) > You can guarantee that the content they had centered is still centered. The things surrounding that content may well change (though in practice this is rarely a problem), but that should be "good enough". Maybe it is not a problem, and works well in practice. Are you doing something like this for Android? > Hence having a decent but imperfect orientation change animation seems far preferable to sacrificing landscape mode, by making the text excessively large (note that when viewing desktop pages in Mobile Safari and N9 text is often too small in portrait mode, so the increased size in landscape can actually be a benefit; but if text had already been an easily legible size in portrait mode, it would be even larger in landscape mode). Sure...
John Mellor
Comment 14 2012-08-22 06:22:30 PDT
(In reply to comment #13) > I am most interesting in how iOS "solved" this. Before iOS 6, if you had a "width=device-width, initial-scale=1" viewport, then the viewport would resize in order to avoid scaling (hence by adding the inital-scale=1, device-width becomes larger in landscape, as in other browsers). However if you did just this, without an accompanying maximum-scale=1, then when rotating from portrait to landscape you would end up zoomed in (by 480/320 = 1.5x). Rotating from landscape to portrait was fine (as iOS doesn't let you zoom such that the page is narrower than the screen). Since iOS 6, if you have such a viewport and rotate from portrait to landscape, you remain at the initial-scale, rather than ending up arbitrarily zoomed in. A relayout will of course occur (as it did before too). > Because it would be best to standardize this in the spec. This whole area is in dire need of speccing. css-device-adapt is a great start, but there are lots of details, corner cases and knock-on effects which are unspecified and implemented differently across browsers (take window.outerWidth for example [1]) :| [1]: http://www.quirksmode.org/blog/archives/2012/03/windowouterwidt.html > > As I explained the same content can be kept in view (e.g. you can be reading the same column, scrolled the same way down it). > > But then you might still need to change the scale to fit the width into the smaller viewport width (going from landscape to portrait) Changing the zoom isn't so bad, since the user can always adjust the zoom later. > > You can guarantee that the content they had centered is still centered. The things surrounding that content may well change (though in practice this is rarely a problem), but that should be "good enough". > > Maybe it is not a problem, and works well in practice. Are you doing something like this for Android? We resize the viewports and adjust Font Boosting when you change orientation, but sadly we haven't yet gotten round to implementing the bit that keeps the same content onscreen. So it works fine for desktop sites without boosting like www.nytimes.com/?nytmobile=0, but for now you do indeed lose your scroll position on sites whose viewport widths change or when there is content above your scroll position which becomes more or less boosted. Of course it's fine if you change orientation before scrolling very far down the page, so it's not quite as bad as it sounds, but we do plan to improve this.
Kenneth Rohde Christiansen
Comment 15 2012-08-22 07:20:07 PDT
(In reply to comment #14) > (In reply to comment #13) > > I am most interesting in how iOS "solved" this. > > Before iOS 6, if you had a "width=device-width, initial-scale=1" viewport, then the viewport would resize in order to avoid scaling (hence by adding the inital-scale=1, device-width becomes larger in landscape, as in other browsers). However if you did just this, without an accompanying maximum-scale=1, then when rotating from portrait to landscape you would end up zoomed in (by 480/320 = 1.5x). Rotating from landscape to portrait was fine (as iOS doesn't let you zoom such that the page is narrower than the screen). Aha, so that is not how it works on the N9 I believe. Because device-width becomes 320 (portrait) and as there is no maximum-scale it will scale it up by 1.8 (1.4 on iPhone) and not expand it to 480. That is how it works with the code in trunk when always using the width from portrait. > Since iOS 6, if you have such a viewport and rotate from portrait to landscape, you remain at the initial-scale, rather than ending up arbitrarily zoomed in. A relayout will of course occur (as it did before too). What if you move away from initial-scale, ie scale it yourself? Can you confirm that they just started using the landscape device-width in landscape? > This whole area is in dire need of speccing. css-device-adapt is a great start, but there are lots of details, corner cases and knock-on effects which are unspecified and implemented differently across browsers (take window.outerWidth for example [1]) :| > > [1]: http://www.quirksmode.org/blog/archives/2012/03/windowouterwidt.html Yes, I also filed a but at W3C for that or was it innerWidth. > We resize the viewports and adjust Font Boosting when you change orientation, but sadly we haven't yet gotten round to implementing the bit that keeps the same content onscreen. So it works fine for desktop sites without boosting like www.nytimes.com/?nytmobile=0, but for now you do indeed lose your scroll position on sites whose viewport widths change or when there is content above your scroll position which becomes more or less boosted. Of course it's fine if you change orientation before scrolling very far down the page, so it's not quite as bad as it sounds, but we do plan to improve this. OK that sounds good.
Kenneth Rohde Christiansen
Comment 16 2012-08-22 07:39:53 PDT
Comment on attachment 159469 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=159469&action=review > Source/WebCore/rendering/TextAutosizer.cpp:95 > +float TextAutosizer::multiplyFontSize(float specifiedSize, float multiplier) I don't know whether we can find a better name. computeFontSizeGivenBaseMultiplier? hmm I don't have any good ideas right now. > Source/WebCore/rendering/style/RenderStyle.cpp:1221 > float multiplier = textAutosizingMultiplier(); Maybe it is good to rename this as it is not the exact multiplication factor anymore
Kenneth Rohde Christiansen
Comment 17 2012-08-22 07:44:13 PDT
computeActualFontSize? :) as suggested by Simon Hausmann.
John Mellor
Comment 18 2012-08-23 04:37:40 PDT
(In reply to comment #15) > Aha, so that is not how it works on the N9 I believe. Because device-width becomes 320 (portrait) and as there is no maximum-scale it will scale it up by 1.8 (1.4 on iPhone) and not expand it to 480. That is how it works with the code in trunk when always using the width from portrait. With jsbin.com/urowoh/45#scale=1 (a simple "initial-scale=1" viewport) on the N9 when you rotate from portrait to landscape the device-width changes from 320 to 569 (press recompute to update the reading). So it seems like you do the same as Apple in that respect. > > Since iOS 6, if you have such a viewport and rotate from portrait to landscape, you remain at the initial-scale, rather than ending up arbitrarily zoomed in. A relayout will of course occur (as it did before too). > > What if you move away from initial-scale, ie scale it yourself? Can you confirm that they just started using the landscape device-width in landscape? If you're slightly zoomed in and rotate from portrait to landscape then you'll end up significantly zoomed in since you'll gain 1.5x zoom (relative to overview; arguably your zoom level is constant but overview zoom level changed) as before. So it seems like they've just special-cased the case where you were in overview zoom level (fully zoomed out), and keep you fully zoomed out after rotating. Conversely if you're somewhat zoomed in and rotate from landscape to portrait you'll lose 1.5x zoom (relative to overview; arguably your zoom level is constant but overview zoom level changed), so if you were only slightly zoomed in you'll end up in overview. (In reply to comment #16) > > Source/WebCore/rendering/TextAutosizer.cpp:95 > > +float TextAutosizer::multiplyFontSize(float specifiedSize, float multiplier) > > I don't know whether we can find a better name. computeFontSizeGivenBaseMultiplier? hmm I don't have any good ideas right now. > > computeActualFontSize? :) as suggested by Simon Hausmann. How about computeAutosizedFontSize? > > Source/WebCore/rendering/style/RenderStyle.cpp:1221 > > float multiplier = textAutosizingMultiplier(); > > Maybe it is good to rename this as it is not the exact multiplication factor anymore Hmm, I can't really think of a better name for it. It's role is essentially still to be a multiplication factor; there's just a slightly subtlety in how it gets applied.
John Mellor
Comment 19 2012-08-23 04:40:23 PDT
Created attachment 160127 [details] Patch Renamed multiplyFontSize to computeAutosizedFontSize.
Kenneth Rohde Christiansen
Comment 20 2012-08-23 04:45:13 PDT
Comment on attachment 160127 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=160127&action=review > Source/WebCore/rendering/TextAutosizer.h:54 > + static float computeAutosizedFontSize(float specifiedSize, float multiplier); Ithought the name TextAutosizer::computeActualFontSize made sense as it is part of TextAutosizer, but this is ok
Kenneth Rohde Christiansen
Comment 21 2012-08-23 04:49:31 PDT
(In reply to comment #18) > (In reply to comment #15) > > Aha, so that is not how it works on the N9 I believe. Because device-width becomes 320 (portrait) and as there is no maximum-scale it will scale it up by 1.8 (1.4 on iPhone) and not expand it to 480. That is how it works with the code in trunk when always using the width from portrait. > > With jsbin.com/urowoh/45#scale=1 (a simple "initial-scale=1" viewport) on the N9 when you rotate from portrait to landscape the device-width changes from 320 to 569 (press recompute to update the reading). So it seems like you do the same as Apple in that respect. Oh really? I wonder whether this changed in trunk or whether it was changed by the N9 browser maintenance team. Adding abinader maybe he knows.
Kenneth Rohde Christiansen
Comment 22 2012-08-23 04:56:11 PDT
(In reply to comment #18) > (In reply to comment #15) > > Aha, so that is not how it works on the N9 I believe. Because device-width becomes 320 (portrait) and as there is no maximum-scale it will scale it up by 1.8 (1.4 on iPhone) and not expand it to 480. That is how it works with the code in trunk when always using the width from portrait. > > With jsbin.com/urowoh/45#scale=1 (a simple "initial-scale=1" viewport) on the N9 when you rotate from portrait to landscape the device-width changes from 320 to 569 (press recompute to update the reading). So it seems like you do the same as Apple in that respect. Nice test page! I though you were talking about initial-scale=1,width=device-width. I tried to test that on the test page but it auto adds maximum-scale=1
Bruno Abinader (history only)
Comment 23 2012-08-23 05:25:42 PDT
(In reply to comment #21) > (In reply to comment #18) > > (In reply to comment #15) > > > Aha, so that is not how it works on the N9 I believe. Because device-width becomes 320 (portrait) and as there is no maximum-scale it will scale it up by 1.8 (1.4 on iPhone) and not expand it to 480. That is how it works with the code in trunk when always using the width from portrait. > > > > With jsbin.com/urowoh/45#scale=1 (a simple "initial-scale=1" viewport) on the N9 when you rotate from portrait to landscape the device-width changes from 320 to 569 (press recompute to update the reading). So it seems like you do the same as Apple in that respect. > > Oh really? I wonder whether this changed in trunk or whether it was changed by the N9 browser maintenance team. Adding abinader maybe he knows. I'm afraid I can't help much, as I can only speak for the non-browser QtWebKit shared library on Nokia N9, as the browser had one library of its own. For the shared library, AFAIK there was no specific patch to address this issue. You can still find the public "mirror" of the N9 patchset [1]. In this case, I'd suggest you write a simple QML WebView that opens the jsbin.com page and check. [1] https://gitorious.org/~adriancjr/webkit/adriancjrs-qtwebkit-maemo6
John Mellor
Comment 24 2012-08-23 07:18:30 PDT
(In reply to comment #22) > Nice test page! I though you were talking about initial-scale=1,width=device-width. I tried to test that on the test page but it auto adds maximum-scale=1 I added an option for that: http://jsbin.com/urowoh/48#device-width,initial=1 Do you think the patch is ready for commit-queue?
WebKit Review Bot
Comment 25 2012-08-23 09:23:53 PDT
Comment on attachment 160127 [details] Patch Clearing flags on attachment: 160127 Committed r126438: <http://trac.webkit.org/changeset/126438>
WebKit Review Bot
Comment 26 2012-08-23 09:23:58 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.