docs(aio): image sweep#16609
Conversation
|
The angular.io preview for c13cd257a1a88be3d5f58fe99a2d319763bea671 is available here. |
c13cd25 to
8294ad3
Compare
|
The angular.io preview for 8294ad311c5579d3ab52a7e0c4cba6312a9d0276 is available here. |
|
The angular.io preview for 025c3299b3ce3f7632f2983dc849a7c08fb2774f is available here. |
025c329 to
9475ec7
Compare
|
The angular.io preview for 9475ec7558e86ea946df54f9229ecd32efcb911f is available here. |
9475ec7 to
383ad5e
Compare
|
The angular.io preview for 383ad5e1c617989fbdeb6c111ccaa0b32cab5711 is available here. |
|
The angular.io preview for ff25d222bcc6437ab5f3a91dd85fcda48b2856c8 is available here. |
ff25d22 to
f487edb
Compare
|
The angular.io preview for f487edb53a91e0b0f47aa3b84b2e2d100b0f58a0 is available here. |
There was a problem hiding this comment.
We only want this formatting of images within the content of documents, not the aio-shell in general.
There was a problem hiding this comment.
If the screen is wider than 1300px then we want to use the width and height values provided in the HTML to ensure that the page is laid out correctly while the images are still loading.
There was a problem hiding this comment.
But then as the screen narrows the images will be constrained by the max-width rule, which means that we need to switch to using height: auto to ensure that the proportions of the image do not change.
f487edb to
151d795
Compare
|
The angular.io preview for 151d7958471fb5b66dc89cb050537f90a49e0e16 is available here. |
151d795 to
68263a1
Compare
|
The angular.io preview for 68263a12d33bdd7f94b73a08ea9b258d44d526de is available here. |
gkalpak
left a comment
There was a problem hiding this comment.
LGTM (with a few minor comments/questions).
There was a problem hiding this comment.
This raw image is super big. A width of 700px is about all you can manage on a screen that is at the breakpoint of 1300px before the max-width: 100% kicks in.
There was a problem hiding this comment.
Shouldn't we resize the image then (and save the cost of downloading it)?
There was a problem hiding this comment.
Yes but that was outside of my remit :-P
I'll create an issue to track it.
There was a problem hiding this comment.
Why do we need manualy width/height here?
There was a problem hiding this comment.
The actual image is too large for the width of the page at the breakpoint where we switch to max-width: 100% and height: auto. 700 is the biggest width that works at this screen width.
There was a problem hiding this comment.
How did you determine these heights. This one looks "sqeezed" for example?
There was a problem hiding this comment.
I was going to comment this one too.
There was a problem hiding this comment.
For each image I set the width to the suggested width and then checked that the browser resized the height to. I may have got it wrong in this case. It should have been 176.
There was a problem hiding this comment.
This left margin doesn't look so goodon narrow screens (where max-width: 100%).
There was a problem hiding this comment.
Good call, we need to lose the floating when narrow, I guess.
There was a problem hiding this comment.
Nit: I think the idea was to make this image the same size as the previous one (which looks better). This behavior is not retained here.
There was a problem hiding this comment.
agreed - will fix
There was a problem hiding this comment.
The .html is only there because the defaults for that processor were: ['', '/', '.html', '/index.html'], so I am really just adding one new one. :-)
There was a problem hiding this comment.
you'd have never known if I'd just used .push('#....').
|
The angular.io preview for f66dc2eda2fdfcbbd444e3a973efd2bc79921a0d is available here. |
wardbell
left a comment
There was a problem hiding this comment.
Same question. I do like baking #top-of-page though.
Otherwise, lgtm
There was a problem hiding this comment.
I was going to comment this one too.
There was a problem hiding this comment.
This in narrow mode is almost invisible.
There was a problem hiding this comment.
Hmm, that is because the image is in a td and it's width gets set to max-width: 100% but that it 100% of the td rather than the page. We might need some additional styling to cope with this situation.
|
The embedded plunker preview images are suuuuuuuuuper big. |
f66dc2e to
84b16a1
Compare
The css rules for `img.right` and `img.left` allow authors easy access to floating an image on the left or right, respectively. The `.image-display` rule which was always found on a figure has been simplified so that all figures have this styling. It is very unlikely that a figure will be used outside the content area; and at this time it seems like `figure` is as good an indicator that we want this kind of styling as anything. Now that images are all tagged with width and height values, we cannot assume to modify these dimensions via CSS as it can cause the image to lose its correct proportions. Until we find a better solition we must set `height` to `auto` when the screen width is below 1300px to ensure that these images maintain their proportions as they get shrunk to fit.
Previously the negative margin on the code headings were causing floated images to overlay the start of a code block. Now all code block successfully clear all floated elements.
Previously, the guides have a lot of inline image styling and unnecessary use of the `image-display` css class. Images over 700px are problematic for guide docs, so those have been given specific widths and associated heights.
The `#toc` anchor does not work when the page is wide enough that the TOC is floating to the side.
Since the `#top-of-page` is outside the rendered docs the `checkAnchorLinks` processor doesn't find them as valid targets for links. Adding them as a `pathVariant` solves this problem but will still catch links to docs that do not actually exist.
This made them look too big, generally. Leaving them with no size means that they will look reasonable in large viewports and switch to 100% width in narrow viewports.
84b16a1 to
1802c5c
Compare
|
I think this is all fixed up @Foxandxss and @gkalpak PTAL |
|
The angular.io preview for 84b16a19f03049bd82acce22cb2937a59aa2b892 is available here. |
|
Works for me pete. |
* fix(aio): allow code blocks to clear floated images Previously the negative margin on the code headings were causing floated images to overlay the start of a code block. Now all code block successfully clear all floated elements. * feat(aio): add a `.clear` class for clearing floating images * fix(aio): tidy up image styles The css rules for `img.right` and `img.left` allow authors easy access to floating an image on the left or right, respectively. The `.image-display` rule which was always found on a figure has been simplified so that all figures have this styling. It is very unlikely that a figure will be used outside the content area; and at this time it seems like `figure` is as good an indicator that we want this kind of styling as anything. Now that images are all tagged with width and height values, we cannot assume to modify these dimensions via CSS as it can cause the image to lose its correct proportions. Until we find a better solition we must set `height` to `auto` when the screen width is below 1300px to ensure that these images maintain their proportions as they get shrunk to fit. * docs(aio): general tidy up of image HTML in guides Previously, the guides have a lot of inline image styling and unnecessary use of the `image-display` css class. Images over 700px are problematic for guide docs, so those have been given specific widths and associated heights. * docs(aio): use correct anchor for "back to the top" link The `#toc` anchor does not work when the page is wide enough that the TOC is floating to the side. * build(aio): add `#top-of-page` to path variants for link checking Since the `#top-of-page` is outside the rendered docs the `checkAnchorLinks` processor doesn't find them as valid targets for links. Adding them as a `pathVariant` solves this problem but will still catch links to docs that do not actually exist. * fix(aio): ensure that headings clear floated images * fix(aio): do not force live-example embedded image to 100% size This made them look too big, generally. Leaving them with no size means that they will look reasonable in large viewports and switch to 100% width in narrow viewports.
* fix(aio): allow code blocks to clear floated images Previously the negative margin on the code headings were causing floated images to overlay the start of a code block. Now all code block successfully clear all floated elements. * feat(aio): add a `.clear` class for clearing floating images * fix(aio): tidy up image styles The css rules for `img.right` and `img.left` allow authors easy access to floating an image on the left or right, respectively. The `.image-display` rule which was always found on a figure has been simplified so that all figures have this styling. It is very unlikely that a figure will be used outside the content area; and at this time it seems like `figure` is as good an indicator that we want this kind of styling as anything. Now that images are all tagged with width and height values, we cannot assume to modify these dimensions via CSS as it can cause the image to lose its correct proportions. Until we find a better solition we must set `height` to `auto` when the screen width is below 1300px to ensure that these images maintain their proportions as they get shrunk to fit. * docs(aio): general tidy up of image HTML in guides Previously, the guides have a lot of inline image styling and unnecessary use of the `image-display` css class. Images over 700px are problematic for guide docs, so those have been given specific widths and associated heights. * docs(aio): use correct anchor for "back to the top" link The `#toc` anchor does not work when the page is wide enough that the TOC is floating to the side. * build(aio): add `#top-of-page` to path variants for link checking Since the `#top-of-page` is outside the rendered docs the `checkAnchorLinks` processor doesn't find them as valid targets for links. Adding them as a `pathVariant` solves this problem but will still catch links to docs that do not actually exist. * fix(aio): ensure that headings clear floated images * fix(aio): do not force live-example embedded image to 100% size This made them look too big, generally. Leaving them with no size means that they will look reasonable in large viewports and switch to 100% width in narrow viewports.
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |




All the images in the guides have been checked and tidied up.
Fixes #16396
@wardbell : The following should become part of the "Authors Styleguide":
Using Images
It is best to use HTML to declare images in the docs. Do not use the markdown
shorthand.
The HTML to use is an
<img src="..." alt="...">tag. You must supply asrcattribute that is relative to the base path; and you should provide analtattribute describing the image for accessibility. Note that Image tags do not have a closing tag.Image Size
The doc generation process will read the image dimensions and automatically add
widthandheightattributes to theimgtag. If you want to control the size of the image then you shouldsupply your own
widthandheightimages.Images should not be wider than 700px otherwise they may overflow the width of the document
in certain viewports. If you wish to have a larger image then provide a link to the actual image that
the user can click on to see the larger images separately.
Image Formatting
There are three types of images that you can put in docs: inline, floating and standalone.
Inline Images
To create an inline image simply place the
imgtag in the content where you want the image to appear. E.g.Floating images
You can cause an image to float to the left or right of the text by applying the
class="left"orclass="right"attributes respectively. E.g.All headings and code-examples will automatically clear a floating image.
If you need to force a piece of text to clear a floating image then you can use the following snippet:
Finally, if you have floating images inside alerts or sub-sections then it is a good idea to apply the
clear-fixclass to thedivto ensure that the image doesn't overflow its container. E.g.Standalone images
Some images should stand alone from the text. You do this by wrapping the
imgtag in afiguretag. This causes the image to get additional styling, such as a rounded border and shadow. The text will not flow around this image but will stop before the image and start again afterword. E.g.
(In the future we may also support styling for adding a caption to a standalone image.)