googlechrome / developer.chrome.com Goto Github PK

https://developer.chrome.com/docs/extensions/mv2/permission_warnings/

The current width is:

.measure-long {
  max-width: 79ch;
}

It wastes 50% of available space and makes some of the content almost completely unreadable. The extension documentation has pages with very wide and deeply nested tables so the overall content width shouldn't be limited at all or it should be a much bigger value.

In Api Reference Table located Here Contains Two Entries of Cookies & They Also Refer Same Content.

Describe the bug
This docs page has several broken links (404's):
https://developer.chrome.com/docs/extensions/mv2/devtools/

To Reproduce
Steps to reproduce the behavior:

• Click "devtools.panels" link which points to https://developer.chrome.com/docs/extensions/mv2/devtools.panels - HTTP 404
  Should point to https://developer.chrome.com/docs/extensions/reference/devtools_panels/

• Click on "Dev Tools Extension Gallery" - https://developer.chrome.com/docs/devtools/docs/extensions-gallery/ - HTTP 404
  I think the gallery is old and gone. Perhaps should point this to https://developers.google.com/web/tools/chrome-devtools/

This is a compromise for today's jarring behavior of opening the nav on hover.
Instead, users have to explicitly activate it but it auto-closes on mouseout.

https://www.google.com/intl/en/chrome/devices/chromecast/apps.html

Just noting the URL. It took me way to long to find it again.

We should copy this CSS directly, instead of writing new CSS based on PSDs that are attempting to represent this CSS. I'm about to do that for the pillar page.

I'm reading the page https://developer.chrome.com/docs/extensions/mv2/getstarted/, and after clicking on some links, they don't exist.

For example, clicking in the

The completed extension can be downloaded here.

Is redirecting to https://developer.chrome.com/docs/extensions/mv2/getstarted/examples/tutorials/get_started_complete.zip, which returns a 404 error.

Great website! 🥳

It seems for some API references the top-level properties have missing type annotations. E.g.:

• https://developer.chrome.com/docs/extensions/reference/extension/#property-inIncognitoContext
• https://developer.chrome.com/docs/extensions/reference/runtime/#property-id
• https://developer.chrome.com/docs/extensions/reference/sessions/#property-MAX_SESSION_RESULTS
• https://developer.chrome.com/docs/extensions/reference/tabs/#property-TAB_ID_NONE
• https://developer.chrome.com/docs/extensions/reference/windows/#property-WINDOW_ID_CURRENT

This is a really nice to have and easy to do in JS. I'm adding it because it's....useful!

Apps/Extensions/Native categories all have large lists of category/pages. They overflow the fatnav. I need to make things smaller and figure out a way to better hand large categories.

The "sidebar" internal-to-the-page navigation (TOC) for articles needs more work. It's supposed to open and close as people scroll down the page. And be pinned to the sidebar (on wider screens) as the user scrolls.

There's also more to be worked out around how it works on narrow screens.

A Black Border Around the Search Bar in Chromium Version 87.0.4280.66 But Looks Normal in Mozilla Firefox developer.chrome.com

The chrome.printerprovider event don't display the event passed parameters making it unusable.
When callback function are used there is no description of the expected input parameter nor number of parameter.

I had to look at the Google search cached page (old page) to get event desciption.

I don't look at other API but it seems the issue is for all event.

In the designs there are icons highlighting content in two places:

Home page:

Pillar page:

I've asked August Navarro from Huge for the original artwork for these graphics, but I haven't heard back from him yet. ([email protected])

Zhu Zhu, designer at Google, has created a mockup showing how she wants these graphics to be grey instead of blue.

Zhu created a photoshop file, and we have the original photoshop file from Huge. But neither of these are vector files. We could create @1x png/gif images from the PSDs, (or make a sprite if we decide we want these to be background styles). But we can't make SVG files or an icon font without first getting originals from Huge, (nor make @2x retina ready images, since the PSDs are too low of resolution).

Hopefully once August is back from vacation we'll hear from him. Meanwhile I wanted to open an issue to note that these icons still need to be added.

Instead, the mobile view kills the TOC and has expanders on the actual content sections:

@Meggin and I chatted. We're going to partition articles content into <section> tags. <h2> headings signify a new section. The "related content" section still appears at the bottom of the article.

Affected page:
https://developer.chrome.com/docs/extensions/mv2/migrating_to_service_workers/

What's going wrong?:
The following URLs on the page linked from the article give 404 on access.

• https://developer.chrome.com/migrating_to_manifest_v3/
• https://developer.chrome.com/docs/extensions/events/
• https://developer.chrome.com/docs/extensions/workers/

The files from Huge show two stylings — one for notes and another for warnings or important notes. One is a tooltip style pop-up, the other is red text inline to the page.

I'm not sure how these are handled in the current CMS, or what the resulting HTML is.

Both need to be styled.

I found two duplicate links.
https://developer.chrome.com/docs/extensions/reference/

I found there is no "Since Chrome version" in new api reference. In the past, there are many statement say like "Since Chrome 48". This information is useful for compatibility. Developers can detect features or set "minimum_chrome_version" in manifest.

There a couple different things going on with the footer background.

The PSDs from Huge have two different treatments:

and

The home and pillar pages have white-background footers. The article page has a solid grey color (even throughout).

On Chrome.com, every page has the same footer treatment — a lint great box that's actually a gradient that fades from a slightly-darker grey at the top of the box to an almost white color at the bottom of the box.

It seems to me all developer.chrome.com pages should have the same grey-gradient treatment as chrome.com.

Thoughts?

In the source paragraph there's "The source code to devleoper.chrome.com will launch after Chrome Dev Summit 2020."

I've created a PR that fixes the typo

Hey,
Are we using any of the images in the directory at static/images? There are a lot in there. I'm assuming that's reference stuff from the Chrome.com dump. I'd like to move them away, so that it's obvious what are real images for this new work, and what's not.

Is there anything in there that you are using @ebidel ?

cc @Meggin @mangini

Same Content is Referenced Twice Here With Title Migrating from background pages to service workers

Chrome.com has a lot of animated bits here and there, which enhance the presentation of the content. The folks at Huge focused on designing flat files in Illustrator and Photoshop, and never mentioned interactivity or motion. I don't think it's something they think about in their process. I believe, however, that since the web is not a printed brochure, motion and animation should be considered. And it would help to match the branding between the two sites.

I added a simple transform to link hovers. It matches a hover transform from chrome.com.

I don't think it makes sense to translate all the animation directly from the product website to the documentation website, since people return to the documentation site over & over, instead of visiting it once. Chrome.com's animation creates the feeling of a product unveiling — aka, "Here is Chrome! Look at this amazing product. Ta da! " Too much of that kind of thing would get on developers' nerves. "Here's the documentation you are looking for!... Ta Da!" is not the right tone.

Some simple transformations could make for nice touches, however. Things that happen quickly, and don't require anyone to wait for the content to be ready to use. Things that feel like subtle enhancements, not obstacles. Things that do match the branding, and simply let people know, hey this is a modern website using some of the latest techniques, because we are smart and build things with new technology.

I thought I'd open a discussion.

As noted in another issue, I'm looking at the markup of the main content on this page: https://developers.google.com/chrome-developer-tools/docs/elements

Hm.

The <p> tags aren't nested properly in places. And both <b> and <strong> are being used in ways that aren't quite correct semantically. And images are marked-up with extraneous divs that we don't need.

How much will there be a chance to clean stuff like this up in the conversion? Or is this markup something consistent and universal that we should support with the new CSS, and just live with? Or is it something that we'll have to live with, but that isn't standardized across pages / not something to "support" because there are a lot of little inconsistent errors created manually over years…

Ah, life. And pickiness.

Change urls in styles to use ../images/* instead of /static/images/*, to proper allow testing in the appengine server where the root dir can be /_patch/, for example.

Describe the bug
The website contains the same api link twice for history API

To Reproduce
Steps to reproduce the behavior:

1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

• OS: [e.g. iOS]
• Browser [e.g. chrome, safari]
• Version [e.g. 22]

Smartphone (please complete the following information):

• Device: [e.g. iPhone6]
• OS: [e.g. iOS8.1]
• Browser [e.g. stock browser, safari]
• Version [e.g. 22]

Additional context
Add any other context about the problem here.

Describe the bug
Some of the pages under https://developer.chrome.com/docs/extensions cannot be accessed. It will result with 404.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://developer.chrome.com/docs/extensions/mv2/manifest/background/
2. You will see "Aw, Snap! We couldn't find that page." error. In developer console you can see "Failed to load resource: the server responded with a status of 404 ()"

The megamenu should be styled to have the background color, borders, and drop-shadows of chrome.com:

Sorry, Eric I didn't know you didn't know that the wireframe pdfs were just wireframes. And not how it should look visually.

We should be able to just grab the CSS from the chrome.com stash. I was going to work on this, but since you are All Things Mega-Menu, I figured I should just drop a note about it and leave it to you.

On https://developer.chrome.com/blog/welcome/ there is the block "Follow us" with 2 icons: YouTube and Twitter. Their path were messed up.

Describe the bug
Linked assets on /docs/webstore/branding are missing

To Reproduce
Steps to reproduce the behavior:

1. Visit https://developer.chrome.com/docs/webstore/branding/
2. Find the table of images assets
3. Attempt to download an image

All asset links 404.

Expected behavior
The linked assets should either load in your browser or be downloaded directly to disk.

Screenshots
The below image shows the table of image assets in question.

Additional context
The missing image assets can be found here: https://github.com/GoogleChrome/webstore-docs/tree/master/images

An empty TOC top level (no children) doesn't allow clicking on it to jump to a top level header. Currently, there are many one-level-depth docs.

Removing the "toplevel" class from empty headers works, but the difference in style between same level headers with (bold) and without children (soft gray) looks weird.

We have a lot of used chromebooks that was enrolled previously. We enrolled it again and it is now a managed device in Google Admin Console. However, when using the API chrome.enterprise.deviceAttributes.getDirectoryDeviceId(), that function returns empty. Not sure why it only happens with previously enrolled chromebooks.

So on chrome.com, the default text size is 13px.

And this size is what's specified in the designs from Huge.

But I think it's way too small.

Especially on screens where the pixel density is really tight (like the iPad mini, for example), the text ends up being very small.

As I roam around studying designs from amazing people who know typography at a deep, deep level, 16px has become a favorite default. It works well on a wide range of screen densities — not too big and not too small.

Of course, there's an accessibility issue here as well as a readability issue. People will significantly-impaired vision will have other solutions — I don't mean them. I'm thinking of the large percentage of the population who's older than 35 and can't easily read tiny, tiny text anymore. 13px on the web is just so small.

There are items on the home page and on the bottom of the pillar page that are setup as three boxes across (for wider screens). There are no gutters on these columns. I'm not sure if there used to be gutters, and I messed up the code that created such gutters, or if they never had gutters. I still just don't get how this grid system works when it's at its best, so @ebidel I'd like to leave this task for you — to fix this.

Links in https://developer.chrome.com/docs/extensions/mv2/devguide/ 404. The URLs are malformed & reference articles assuming the previous site's structure.

Originally reported by @Mewel in #41 (comment)

The latest designs show a circle with an arrow pointing down. But on chrome.com, they are a lighter blue. We should copy chrome.com. I found this example randomly, searching for something else, so I thought I'd make a note in a ticket here so it's easier to find later.

https://www.google.com/intl/en/chrome/devices/features/

Should look like this:

I'm using this page as an example of content as we work: https://developers.google.com/chrome-developer-tools/docs/elements. So I've been looking at the HTML of the page.

None of the images have alt text. They really should.

This isn't a development bug, it's a content workflow / CMS tooling / culture issue. Something to talk about. There are a lot of people who are both professional developers and screen reader users. I personally know two. I'd love to see Google's Chrome Developer documentation include them.

I'm about to re-implement the pillar page layout using Flexbox instead of the current floats. Trying to set the height of these boxes to a fixed amount to work across a variety of widths with different content is a crazy fox chase that I'd rather not start. Flexbox will be faster than writing a bunch of tweaks to the height across a dozen of media queries (what I've done in the past for situations like this) — and it will result in a much better layout.

I'm thinking of implement Chris Coyier's mix of old and new flex box syntax to cover most browsers: http://css-tricks.com/using-flexbox/

The only holdout with that technique is IE9. We aren't supporting IE 6,7,8, right? Do we need to worry about IE9? I can easily add a conditional class on the html element and move the current layout CSS into an IE9-only stylesheet (with giantly-tall heights on each box). Or we can leave this page with no layout for the seven ie9 users. People will still see the content, it'll just be in a tall, thin single column.

Thoughts @ebidel ?

You Can Find it Here

OK got it button is missing on Edge (right)

Edge version 45

Side menubar is not opening on Edge (right)

Some links need to be updated e.g. links to the overview of 'message passing' are currently incorrect as https://developer.chrome.com/docs/messaging/ -> should be https://developer.chrome.com/docs/extensions/mv2/messaging/

I went to https://developer.chrome.com/docs/webstore/branding/ and it seems that all links that start with https://developer.chrome.com/docs/ from the branding page are broken. This includes for example links to the branding icons and terms of service.