[css-page-3] Add orientation descriptor #4491
Comments
|
No strong opinion on the proposal here. This would map directly to the |
|
Printing devices will all rotate the pages to fit the available media anyway, they won't need the hint. Yes, if we were implementing this we'd map to the Rotate entry on the PDF Page object, which can take any multiple of 90 as a valid value. Presumably the intention here is to try and get all the pages the same size on screen? So if you have a single landscape page halfway through a document, for example, you can rotate it to make it visually the same dimensions as the rest of the document? I can see an argument for that - it would help PDF viewers to choose the initial display settings fo the document. But I can't think of any other reason for this myself. If that's the intention then I personally prefer "orientation: portrait", which could leave pages that are originally portrait pages untouched and rotate only landscape pages, over "orientation: 90" or "orientation: rotate-right" |
|
The CSS Working Group just discussed The full IRC log of that discussion<dael> Topic: [css-page-3] Add orientation descriptor<dael> github: https://github.com//issues/4491 <fantasai> Issue for use cases at https://github.com//issues/4585 <dael> chrishtr: Way to rotate page w/o changing layout. Different rotation in PDF is the use case. Intended is to set rotate descriptor in PDF. <dael> florian: Wouldn't do anything if print to actual paper? <dael> chrishtr: Right <dael> florian: Sure <fremy> sounds useful <dael> TabAtkins: Reasonable to me. Not sure if it's better to do explicit direction keywords or portait. Happy to advance <dael> florian: Suspect picking direction is useful <dael> chrishtr: I can imagine left or right depending on visual preference <dael> florian: If you're not controlling...no, I guess MQ. If you don't decide if the whole should be portrait or landscape you can use MQ to decide a section <dael> fantasai: I don't think prtrait vs landscape is sufficient b/c you might want to rotate +90 or -90. You want to rotate entire page <dael> dbaron: This would be clearer with examples as to what is and isn't rotated <dael> florian: No effect to layout, just set a flag in PDF <dael> dbaron: Not just that. Could use examples saying this pair of size and oritentation should look like this. In terms of what PDF looks like vs page and content orientation <dael> chrishtr: I can add example <dael> AmeliaBR: Would be helpful. I think...visually for me is a PDF mostly portait and we want to display a page in landscape or is it that page is layout in landscape but display as portrait. Which cases? <dael> fantasai: Things relevent here is reltationship of content to page box. Headers and footers to page box. Orientation of page box itself. <dael> fantasai: I can interpret this is 2 ways. Only changes oritientation of page, but header is still at top or it layouts entire content incl. header and then rotates. I'm not sure about it. <dael> florian: Some section sin landscape can handle with page sizing. Don't need something to change aspect ratio of some pages <dael> AmeliaBR: But having headers match other pages is the missing <fantasai> The landscape keyword on size doesn't affect orientation <dael> florian: I thought it was print the 3rd page rotated 90deg. Examples would help <fantasai> it's a shortcut for sizing <dael> chrishtr: That's what I intended. Hand't thought detail on header/footer <florian> s/print the 3rd page rotated 90deg/print normally, then physically rotate the 3rd piece of paper/ <dael> Rossen_: Intended for anything outside page. Could this be used in regular HTML? Thinking of ePub where people might want similar control. Why is this PDF specific? <fantasai> Not PDF-specific, but @page specific <dael> Rossen_: Kinda goes back to lack of examples. What is this intended to solve? I clearly hear PDF. I don't believe we want per page control. In summary it goes back to getting clearer examples in proposal <myles> q+ <Rossen_> ack fantasai <dael> fantasai: I want to clarify landscape keyword on size is just a shortcut to say I want 11x8.5. Please don't confuse orientation with that keyword. <dael> fantasai: Second point, I think we want it to apply to more than PDFs. Proposal is descriptor on @page rule which talks about page box for paged media. <dauwhe> q? <dael> florian: I think it applies to most but not all paged media. Doesn't apply to paper b/c if you're printing to paper how you position the pages is out of our control. But if you're in a PDF that's different b/c renderer can decide how to layout pages. <dael> fantasai: In terms of some pages oriented one way vs another we have a feature that allows us to assign content to different types of pages. This section is on legal where rest is on letter. An orientation descriptor lets you do somehting similar where this chapter is landscape. That falls from existing fucntionality <dael> TabAtkins: It is appriclable to paper. Controlling which direction the landscape grapth is in a paper book is worthwhile. Printer will auto rotate but if you have it oriented you stick with that. <dael> florian: I was thinking of home printer, but yes if you're binding that makes sense <dael> myles: You guys said much of what I would say. We have a size descriptor already. If goal is to let your big table be printing on landscape you can do that. only value is what TabAtkins said where for printed context it tells the printer what to do. For PDF it's no effect b/c you can do the use case. Only way this makes sense if if it's no effect on PDFs <Rossen_> ack myles <dael> TabAtkins: Makes sense ofr PDF. If layout in landscape but want to display PDF as portrait you can do that <dael> AmeliaBR: Overrides the default PDF view where if it's landscape it displays landscape. Forces to show in the printed book fasion <dael> myles: Why would anyone want that? <dael> TabAtkins: DnD books for example that have a wide table. Page is pointed vertically. Want to have PDF match look of book is reasonable <dael> myles: Don't have have to turn your computer to read it? <dael> TabAtkins: Sure <dael> AmeliaBR: Other case of content in landscape but headers in portrain you can do with writing mode <dael> florian: Can't do by page can you? <dael> AmeliaBR: You can say this section has vertical writing mode and that effects content <dael> TabAtkins: As we come to end of hour, seems like some disagreements about when applicable. Seems reasonable to do. Open question as to if it changes header position. Good to look at use cases to see which the use cases prefer. If it's mixed we can look at a switch <dael> florian: So if page margin boxes areorthogonal to content <dael> fantasai: yes <dael> florian: Can't you do that with writing modes? <dael> fantasai: Yes <dael> Rossen_: chrishtr will you add the use cases? Or TabAtkins ? <dael> TabAtkins: I volunteer chrishtr are tribute <dael> fantasai: It's not just page margin boxes this effects Question is do we disassociate content from the concept of t/b/l/r from the page's concept or are we rotating the whole page? Does that oage's concept of t/b/l/r match the content's <dael> TabAtkins: Don't think can lay out a top margin box that would layout as a tall skinny thing. Need to know if layout into tall skinny or squat wide. <dael> fantasai: Separate thing <dael> florian: My udnerstanding is it rotates the whole page. And then use writing modes etc to make changes <dael> fantasai: Prop easiest <astearns> s/are tribute/as tribute/ <fantasai> I think also we agree that 'orientation' should take 4 orientations, not just landscape/portrait <dael> Rossen_: We're at the hour please add thoughts to the issue. <dael> Rossen_: We've got 2 issues left that we'll start with next week <fantasai> and probably should use syntax consistent with 'image-orientation' even though it's awkward |
|
An example of the case of rotated content within portrait page layout. Again, I think this is handled by writing-mode on the rotated table:
|
|
In contrast, the use case being discussed here is where the complete layout of certain pages (headers/footers, and any margins defined for the page) uses a different orientation from the rest, but you want to display all the pages oriented as they would come out of the printer. As Tab says, this would also ensure that when printing & binding they are oriented as intended. (And therefore, the property would need to distinguish between rotated clockwise vs counterclockwise!) But… I couldn't find any good examples of that type of PDF in a quick poke around my computer. |
|
I thought of another use case: imagine the book layout above, with headers/footers in portrait mode, since that looks best for printing. But for viewing the digital file, it would be much more useful if the PDF pages were displayed in landscape mode, so that the table isn't sideways on your screen. How would that work with these new descriptors? |
|
This sort of thing (lets call this "image 2")?
I had a look. We have thousands of PDF here but I have struggled to find an example of what this issue describes it's trying to achieve. Generally, if you have a landscape page in the middle of a generally portrait document, it's displayed as landscape. The idea in Amelias third comment, immediately above, is more common: the page has been laid out entirely in portrait, but with some of the content sideways. You then want to rotate that page from portrait to landscape to get it the right way up, like this one (lets call this "image 3"): |
|
I can think of a surprisingly well-known case where the original viewing condition of the medium is portrait (or spread), but for special pages, the medium needs to be rotated by a quarter-turn although the viewing mode and page layout remains portrait: centerfolds. In some cases, i.e. gatefolds, they are not folded at all, but a magazine with A4-spread has an full-sheet A3 poster in the middle. Is that covered by this issue? |
|
Sorry for the long delay, I got caught up in many other issues. TL;DR: Introduce a new Purpose: apply rotation to PDF output in cases where the most important content has a different orientation than the one from layout. Semantics: the entire content of the page is rotated when In cases where page content has mixed orientation, such as headers and footers differing from page contents rotation, this will result in the header being drawn "sideways" in a PDF display, but as mentioned in the use-case analysis below, this is desirable. Detailed comments below. Some printing folks in Chrome also looked through various data sets and found examples similar to the ones mentioned in previous comments. They also didn't find examples of the entire page rotating with headers, without already drawing the content in a layout PDF page. Instead, it can be common to have content whose internal sizing fits better to landscape than portrait, so as to have two rotations in the same page. The reasons include:
In addition, the headers and footers often have orientations that conflict with the orientation of the content, because the printed page is meant to be presented in a book or pamphlet with a single orientation for each page. The reader of the book is expected to turn it when reading the rotated sub-content. The original motivation for filing this issue was use case 3. In particular, a word processor such as Google Docs has a different layout and formatting system than the web, and for these reasons performs its own layout and may even draw the results to Canvas instead of DOM elements. On top of this, such "web-based" word processors can often support page sizings that are more advanced or specialized than the user agent's. (*) (*) Examples: Chromium and WebKit only have limited support for variable-size/shape pagination. OTOH, a word processor often wants to be able to print mixed page sizes and orientations. Regardless, however, it's easy to see that there are plenty of offline, legacy or otherwise non- "web-based" word processors or content generation systems that are unable to generate DOM output, but that nevertheless benefit from being integrated into web content for viewing or printing. |
|
So just to ensure I'm understanding this right: I have a paged document that's mostly portrait, but I've got a wide table on one page that is best displayed landscape. I set up my When viewed as a PDF, every page flows vertically, as normal for English, and the headers and footers on every page agree with the flow of the content - on the portrait pages, When printed, because the printer doesn't reorient the sheets of paper internally, they'll all be arranged portrait-style in the printed stack, and the landscape pages (both the content and the margin areas) will be "sideways", with the reader expected to turn the entire book to read those pages. So this That's the intended behavior? |
It's the other way around. As far as the layout engine of the browser would be concerned, each page has a base layout size of portrait, and would be laid out accordingly. Therefore, without an |
|
Okay, so the case is that the thing assembling the pages knows how to produce a page of content that's "sideways" (landscape-oriented content, but using Then, for the purpose of viewing in a browser, you can set Okay, so I accept this as being a reasonable solution for your case 3 (legacy system outputting portrait-oriented bitmaps for pages), but it's completely backwards for cases 1 (wide table) and 2 (wide image), which both want to use It also means that we're privileging the "view as printed/bound" case over the "view on the web" cases, requiring the author to know they have to intervene with the So I think it should instead be pointed as a margin-orienting feature, like Then the "legacy tools output portrait-oriented bitmaps" would use this by putting the intended-landscape image on a Thoughts? |
The orientation descriptor is just for printed output. I think it's ok to have a few CSS properties that are just for controlling printing. Printing is part of the web after all. These orientation descriptors should only be within an @media print section. For a "view on the web" mode of the same site, if there is content that is best viewed with a landscape aspect ratio, then the site should just lay out the content in a landscape manner; there are many ways to do that already. What is different about printing (or PDF viewing) is that there is a physical or virtual page that is external to the web on which content is printed. The system that might view a PDF can't re-do layout, it can only rotate around the page.
In addition to my other arguments about why this is not the best way to do it, there is a very practical one, which I alluded to in my previous comment when I said the "limited support". To support |
Also, in the use cases I mentioned, there is an explicit need for the printed output on paper to differ from an "expected view rotation" when viewed digitally in a PDF viewer. |
|
The only use-case described so far seems to be to "undo" the layout decisions made by some layout engines that rotate landscape content into a portrait format. Have I understood that correctly? Are there any use-cases for this property beyond that? Without being able to describe a situation where a member of the general public might use this, it seems a little... specialized for a property baked into a public specification. I also wonder how the following would work:
|
I don't think that's accurate. The use case is to apply a rotation to the "most important" direction of text, in cases where there are multiple orientations on the same page for printed output. To your questions about deciding whether certain parts of the page should be rotated or not - I think that's not the best way to think about it. It's that the page has a particular printed output that includes rotated text in various combinations, for multiple reasons. |
|
OK. I'm not hugely invested in this one way or another so I will say my piece and go away. I'm struggling because I can't imagine a general use-case that demonstrates how to get content onto the page that isn't already upright, according to its "most important direction", in the first place.
In both cases you would have to work much harder to display this content sideways on a portrait page. For a large image, for example, you'd have to override I can see that there might be some value in rotating the margin content in this case - for example, in Amelia's example above, if I were tasked with laying this table out in CSS I'd make it a landscape page. But if I knew it was being destined for a printed book, I might want to rotate the margin content by 90°, so when it's printed and bound, in portrait, the margin content is the right way up. I think that's the opposite of your suggested purpose, but I suppose it's literally a question of perspective so perhaps it will do as a use-case. For background: underlying my concerns is that the "Rotate" parameter in PDF is not great. It's not a simple Affine transformation - it rotates the page content, yes, and the coordinates of any annotations on the page. But the internal contents of those annotations are further rotated to try to keep them up the right way up. This doesn't matter if all you're doing is putting out static content, but if you're creating a PDF with form fields on it then creating the page with the correct orientation in the first place is a lot cleaner than creating the page sideways and setting "Rotate" to 90 or (worse) 180. Clearly your intent is not to replace |
If the page is landscape then headers will also be landscape, right? Which is not desired. |
As far as I can tell from your use-case description and described behavior, it's the exact opposite. From your description of the use-case, it's for when you're rendering to a PDF or other page-based screen media. In the case you described, all the pages are My suggested inversion was the "just for printed output" version, where screen/PDF display works correctly by default (by using (@faceless2 hits on this independently, realizing that the semantics they find reasonable are the opposite of what's being presented here.)
Okay, that's a completely different use-case, and one we can talk about reasonably, but has nothing to do with the other use-cases based on observable behavior of a conforming implementation. If the use-case is "we don't expect to ever actually implement |
When I said "for printed output", I mean that the printing use case. PDF generation is a kind of printing, it's not "view on the web".
Browsers don't have any distinction between PDF and non-PDF printed output, do they? PDF output is an implementation detail of the user agent outside of the control of the web developer.
This is another motivation, yes. However, I don't agree with the notion that this is a hack. The other proposed solutions, as far as I can tell, imply a very large amount of implementation work (even more than just implementing full fragmentation, because there is the proposed additional feature of rotating headers and footers differently than the page layout). Therefore this solution is has positive design points for the (valid, non-hack) use-cases stated. |
I think that's false (i.e. it is desired) if the page is being displayed as landscape on screen - the pages are oriented to match their "most important direction", all the text is up the right way, no-one has to turn their head sideways to read anything. But I think it's true if the page is being printed and bound into a book where all the pages are going to wind up as portrait regardless of their original orientation. In that case, yes, as I mentioned before I can see this being a use-case for some sort of parameter. But again, I would personally lean towards the concept of "rotating the margin content sideways" rather than "rotating the page content sideways". |
I see your point that it's more readable on a screen to see everything in the same orientation. But the use case here is a PDF preview of printing, which is outside the control of the web platform, and therefore requires some parameter to help it out. Right? |
|
Sure - you've convinced me that some sort of parameter indicating a page is to be oriented contrary to it's "most important direction" is probably useful. I'm imagining the printed material, you're imagining the screen preview of the same, but I think we're finally on the same page (badum tish). |
They don't expose any distinction, no. But this feature distinguishes those two cases; your proposed
It's absolutely a hack, because it requires you to write your content in the wrong orientation for screen, to get this desired display when printing. Using 'writing-mode' to make a table lay out "sideways" so that, when printed, it'll get landscape dimensions from a I understand that actually doing breaking across different-sized fragmentainers/pages is still far off in our impl (Ian says ~2 years), so if we want to address this use-case in the short-term we'll need something hackier like this, and I'm fine with that. I just want a different name to emphasize that fact! I'm not sure what the name should be though. :( |
However, there are other legitimate use-cases that will remain even after such features appear in the future (as mentioned earlier, and @faceless2 agreed are legitimate. How about |
Yup, I also agree that having the ability to dictate the relative rotation of the page content vs the margins is worthwhile in the future. My ideal to achieve the use-case here is: table.big {
page: big-table;
}
@page big-table {
size: landscape;
mismatched-orientation: rotate-out;
}...which would be normal on screen, would show a landscape page in PDF (with @top on either the left or right), and would be printed on portrait paper such that the @top margin is on top, and the table is rotated in the "out" direction (right on right pages, left on left pages).
Maybe? Given how targeted this is at the PDF use-case, maybe |
|
Both Not quite sure about
|
|
Thanks for offering suggestions. "print-rotate", "page-rotate" and"orientation-correction" all sound reasonable to me! I don't think it's good to put a particular output format like "pdf" in the name. |
|
Yeah, I wasn't happy with pdf-rotate either. page-rotate seems good to me; you're literally rotating the page itself, but nothing else changes about the layout or display. |
|
The CSS Working Group just discussed
The full IRC log of that discussion<dael> Topic: [css-page-3] Add orientation descriptor<dael> github: https://github.com//issues/4491 <dael> chrishtr: Discussed in Dec. Can add to a named page to control rotation in printed output. <dael> chrishtr: Use cases are to provide orientation for dominant content direction when multi direction. Second it allow dev to provide mixed rotations for UA that don't support other page rotation parts <dael> chrishtr: I think some consensus use cases make sense. <dael> chrishtr: Discussion on name <dael> chrishtr: Check for consensus and then do name <fantasai> https://github.com//issues/4491#issuecomment-590613842 <dael> fantasai: Not clear on the behavior of this. I read TabAtkins comment that makes sense but you said it's not that <dael> TabAtkins: What happens is in cases where printed output but you control how pages are displaded, aka pdf, adjusts how they're oriented in that display. <dael> TabAtkins: You can have a whole bunch of portrait and then some are landscape <dael> fantasai: Example in comment. Doc with a table, assign table to landscape with features we have. Printer the landscape is oriented to portrait. When open a PDF you get a bunch of portrait pages and a landscape for the page that has a table which is upright for me on the screen. THat's without this property. Current behavior <bkardell_> https://docs.google.com/document/d/1plEqcBz_6ApmtWYCSRxwOANgF5aGoAL2B0s_9PSQJF0/edit#heading=h.zd7icrtuskjo <dael> fantasai: Prop is to rotate the landscape so it's sidewas and you have to turn your head to read? <dael> TabAtkins: It's something else <dael> fantasai: What is the default that should happen right now? <dael> TabAtkins: Ideally you do what you desc. Wide table you force to a named page and say landscape <dael> TabAtkins: In scenario today where browsers do not have ability to do diff size page sin layout what you instead do is layout everything as portrait. If that means putting out bitmaps or whatever it all comes out as portrait. <dael> TabAtkins: This feature then says if you're output to a pdf go ahead and rotate. This is a the good feature isn't impl so let's put in this feature for now. It'll be a few years before browser can address properly <dael> fantasai: Okay, I think I understand. So this rotates whole paper including headers <dael> TabAtkins: Correct. <bkardell_> q+ <dael> TabAtkins: When browser can control paper orientation is this property <astearns> ack bkardell_ <dael> fantasai: Use case you're bringing up is you pre-rotate and then rotate back to get effect of if we had portrait/landscape <dael> TabAtkins: Correct <dael> bkardell_: I shared a google doc from gsuites that talked about uses involving mixed orientations. Is that included here? <dael> chrishtr: mixed means some landscape and some portrait. Use case from TabAtkins is a browser that doesn't fully support to still be able to output. <dael> bkardell_: I see that in issue. THanks <fantasai> s/Use case/So your original comment is correct, and the additional use case/ <fantasai> s/pre-rotate/pre-rotate using writing-mode or transform or something/ <dael> astearns: Currently for output formats that can handle layout orientation. When browser can layout as a landscape page owuld this property start applying to on screen? <dael> fantasai: No <dael> TabAtkins: Not unless display in paged format which generally don't <dael> chrishtr: If site applies page:landscape and rotate:left you get things that look sideways. Shouldn't do that. SHould only apply rotate for layout of printed mode <dael> astearns: I'm thinking of paged view on tablet. Currently...if you had this you could layout such that someone can rotate screen and get better view of horz content <dael> chrishtr: Cases where drown by dev layout but paginated layout? <dael> astearns: Future browser with paginated ux <dael> TabAtkins: Got it. Depends on if it allows rotation of pages. If wants to be more like printed it would not respect. BUt if it's just layout onto desktop screen it would respect this property and rotate the page for you <dael> chrishtr: If you consider pdf viewer on tablet you can imagine browser to integrate with pdf viewer to not respect this and expect you to rotate. It's an option impl could choose <dael> fantasai: It's a good point astearns and we should write up that situation <dael> astearns: I've got people with defined opinions on pdf viewers we can consult <dael> TabAtkins: Want to make sure it's clear in description where this applies. Paginated viewing and makes sense to author oritentation of page based on user preference not device orientation. Happy to work together to make sure text looks good <dael> astearns: Other questions or opinions on basic design before we do naming? <dael> astearns: Let's talk names <dael> astearns: My opinion is page-rotate makes sense since talking pagination <dael> chrishtr: Makes sense to me <dael> astearns: Other opinions? <dael> astearns: We're not setting anything in stone. I think for now go with page-rotate and with issue discussion <dael> fantasai: page-rotate or page-orient. rotate left and right makes sense <dael> TabAtkins: I like rotate because it's spinning. I would accept orientation <dael> fantasai: I think that was my opinion until PDF cases where this is a hint about correct orientation but you might not honor that. It's hint about orientation but not a command to rotate. I'm not super clear <dael> astearns: In order to prevent a verb should it be page-rotation? <fantasai> s/PDF cases/astearn's examples,/ <dael> astearns: Seems like we're at a lull. Should we resolve on name page-rotation? <dael> fantasai: Have rotate property <dael> TabAtkins: But it's a rotate function. There's a reason for it to be a verb when we normally have adjectives <dael> fantasai: I feel inconsistency is not great <dael> dholbert: Rotate sounds like an angle rather then keyword <dael> TabAtkins: Breaking with rotate is good <dael> TabAtkins: Page-oreitnetation <dael> chris: People talk about page orientation <dael> chris: page-orientation rotate-left and rotate-right? <dael> astearns: Makes sense. Rotate seems angle <dael> astearns: page-orientation with values rotate-left and rotate-right <dael> dholbert: Don't love rotate-left b/c sounds like clockwise and counter clockwise. Left is direction rather then rotation. It's translation <dael> chrishtr: left is 90deg rather then rotate <dael> dholbert: Suggests counterclockwise <dael> astearns: And easier to spell <dael> astearns: Other concerns? <dael> astearns: Objections? <dael> RESOLVED: Name this page-orientation with values rotate-left and rotate-right <dael> astearns: Anything else you wanted on this chrishtr ? <dael> chrishtr: That's it, thank you |
|
Should we be aligning on the value space for Also |
|
Yeah, with "orientation" "none" doesn't make sense. "upright" works for me. ("page-rotate: none" was more reasonable) |
This will be supported in @page rules to set the orientation of a page (without affecting layout). Typically to be used together with named pages (or @page :first, etc.) See https://drafts.csswg.org/css-page-3/#page-orientation-prop and w3c/csswg-drafts#4491 The tests added have some failures, due to crbug.com/1079212 and crbug.com/1079214 Bug: 1053768 Change-Id: I96f93e3e34beee92b4c30f65d7e46498a8110464
This will be supported in @page rules to set the orientation of a page (without affecting layout). Typically to be used together with named pages (or @page :first, etc.) See https://drafts.csswg.org/css-page-3/#page-orientation-prop and w3c/csswg-drafts#4491 The tests added have some failures, due to crbug.com/1079212 and crbug.com/1079214 Bug: 1053768 Change-Id: I96f93e3e34beee92b4c30f65d7e46498a8110464 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2187211 Reviewed-by: Rune Lillesveen <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Chris Harrelson <[email protected]> Commit-Queue: Chris Harrelson <[email protected]> Cr-Commit-Position: refs/heads/master@{#766534}
This will be supported in @page rules to set the orientation of a page (without affecting layout). Typically to be used together with named pages (or @page :first, etc.) See https://drafts.csswg.org/css-page-3/#page-orientation-prop and w3c/csswg-drafts#4491 The tests added have some failures, due to crbug.com/1079212 and crbug.com/1079214 Bug: 1053768 Change-Id: I96f93e3e34beee92b4c30f65d7e46498a8110464 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2187211 Reviewed-by: Rune Lillesveen <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Chris Harrelson <[email protected]> Commit-Queue: Chris Harrelson <[email protected]> Cr-Commit-Position: refs/heads/master@{#766534}
This will be supported in @page rules to set the orientation of a page (without affecting layout). Typically to be used together with named pages (or @page :first, etc.) See https://drafts.csswg.org/css-page-3/#page-orientation-prop and w3c/csswg-drafts#4491 The tests added have some failures, due to crbug.com/1079212 and crbug.com/1079214 Bug: 1053768 Change-Id: I96f93e3e34beee92b4c30f65d7e46498a8110464 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2187211 Reviewed-by: Rune Lillesveen <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Chris Harrelson <[email protected]> Commit-Queue: Chris Harrelson <[email protected]> Cr-Commit-Position: refs/heads/master@{#766534}
…only Automatic update from web-platform-tests Add page-orientation descriptor. This will be supported in @page rules to set the orientation of a page (without affecting layout). Typically to be used together with named pages (or @page :first, etc.) See https://drafts.csswg.org/css-page-3/#page-orientation-prop and w3c/csswg-drafts#4491 The tests added have some failures, due to crbug.com/1079212 and crbug.com/1079214 Bug: 1053768 Change-Id: I96f93e3e34beee92b4c30f65d7e46498a8110464 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2187211 Reviewed-by: Rune Lillesveen <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Chris Harrelson <[email protected]> Commit-Queue: Chris Harrelson <[email protected]> Cr-Commit-Position: refs/heads/master@{#766534} -- wpt-commits: f8ad4cf5d37166c24ef2b464414b3ebee59595ac wpt-pr: 23454
…only Automatic update from web-platform-tests Add page-orientation descriptor. This will be supported in @page rules to set the orientation of a page (without affecting layout). Typically to be used together with named pages (or @page :first, etc.) See https://drafts.csswg.org/css-page-3/#page-orientation-prop and w3c/csswg-drafts#4491 The tests added have some failures, due to crbug.com/1079212 and crbug.com/1079214 Bug: 1053768 Change-Id: I96f93e3e34beee92b4c30f65d7e46498a8110464 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2187211 Reviewed-by: Rune Lillesveen <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Chris Harrelson <[email protected]> Commit-Queue: Chris Harrelson <[email protected]> Cr-Commit-Position: refs/heads/master@{#766534} -- wpt-commits: f8ad4cf5d37166c24ef2b464414b3ebee59595ac wpt-pr: 23454
…only Automatic update from web-platform-tests Add page-orientation descriptor. This will be supported in @page rules to set the orientation of a page (without affecting layout). Typically to be used together with named pages (or @page :first, etc.) See https://drafts.csswg.org/css-page-3/#page-orientation-prop and w3c/csswg-drafts#4491 The tests added have some failures, due to crbug.com/1079212 and crbug.com/1079214 Bug: 1053768 Change-Id: I96f93e3e34beee92b4c30f65d7e46498a8110464 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2187211 Reviewed-by: Rune Lillesveen <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Chris Harrelson <[email protected]> Commit-Queue: Chris Harrelson <[email protected]> Cr-Commit-Position: refs/heads/master@{#766534} -- wpt-commits: f8ad4cf5d37166c24ef2b464414b3ebee59595ac wpt-pr: 23454
…only Automatic update from web-platform-tests Add page-orientation descriptor. This will be supported in @page rules to set the orientation of a page (without affecting layout). Typically to be used together with named pages (or @page :first, etc.) See https://drafts.csswg.org/css-page-3/#page-orientation-prop and w3c/csswg-drafts#4491 The tests added have some failures, due to crbug.com/1079212 and crbug.com/1079214 Bug: 1053768 Change-Id: I96f93e3e34beee92b4c30f65d7e46498a8110464 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2187211 Reviewed-by: Rune Lillesveen <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Chris Harrelson <[email protected]> Commit-Queue: Chris Harrelson <[email protected]> Cr-Commit-Position: refs/heads/master@{#766534} -- wpt-commits: f8ad4cf5d37166c24ef2b464414b3ebee59595ac wpt-pr: 23454
…only Automatic update from web-platform-tests Add page-orientation descriptor. This will be supported in @page rules to set the orientation of a page (without affecting layout). Typically to be used together with named pages (or @page :first, etc.) See https://drafts.csswg.org/css-page-3/#page-orientation-prop and w3c/csswg-drafts#4491 The tests added have some failures, due to crbug.com/1079212 and crbug.com/1079214 Bug: 1053768 Change-Id: I96f93e3e34beee92b4c30f65d7e46498a8110464 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2187211 Reviewed-by: Rune Lillesveen <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Chris Harrelson <[email protected]> Commit-Queue: Chris Harrelson <[email protected]> Cr-Commit-Position: refs/heads/master@{#766534} -- wpt-commits: f8ad4cf5d37166c24ef2b464414b3ebee59595ac wpt-pr: 23454
…only Automatic update from web-platform-tests Add page-orientation descriptor. This will be supported in @page rules to set the orientation of a page (without affecting layout). Typically to be used together with named pages (or @page :first, etc.) See https://drafts.csswg.org/css-page-3/#page-orientation-prop and w3c/csswg-drafts#4491 The tests added have some failures, due to crbug.com/1079212 and crbug.com/1079214 Bug: 1053768 Change-Id: I96f93e3e34beee92b4c30f65d7e46498a8110464 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2187211 Reviewed-by: Rune Lillesveen <[email protected]> Reviewed-by: Anders Hartvoll Ruud <[email protected]> Reviewed-by: Chris Harrelson <[email protected]> Commit-Queue: Chris Harrelson <[email protected]> Cr-Commit-Position: refs/heads/master@{#766534} -- wpt-commits: f8ad4cf5d37166c24ef2b464414b3ebee59595ac wpt-pr: 23454
TL;DR
Add the ability to rotate the rendered output of a page, for use in cases such as PDF output, and as a hint to printing code & devices.
Details
Currently, the level 3 paged media spec has a size property. This specifies the per-page constraints on layout.
It would be useful to also have an
orientationdescriptor, which could have values ofportraitandlandscape(*). This indicates the orientation of the final rendered page itself, without affecting layout. For example, if content had:It would mean to layout the content in landscape layout mode, but then rotate the resulting rendered page sideways. If the print ended up in a PDF, then a user viewing the PDF would see the page visually rendered with height taller than width, and the content rotated 90 degrees.
This is useful in order to customize the visual display of a PDF, which is a very common way to "print" web pages.
(*) Alternatively, it could have three (four?) values: none, rotate-right, rotate-left (, upside-down?)
@xfq @fantasai
The text was updated successfully, but these errors were encountered: