New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Responsive design commit series #1878

Merged
merged 7 commits into from Apr 11, 2018

Conversation

Projects
None yet
3 participants
@dbs
Contributor

dbs commented Apr 2, 2018

This branch includes a series of commits meant to improve the responsive design of schema.org for device display, and is meant to be the first steps towards addressing #490. More can certainly be done, but this is much more usable than the current experience, and makes very little impact on existing large-screen displays.

dbs added some commits Apr 2, 2018

Responsiveness: remove global font-size: 75%
Use the default font size and allow users to adjust up or down if necessary.
75% can be quite hard to see on modern high-resolution screens, for example.

Signed-off-by: Dan Scott <dan@coffeecode.net>
Responsiveness: set min-width and max-width only for large media
If the width of the display media is greater than 960px, then we can set the
min-width and max-width accordingly. Otherwise, let's leave that unspecified
and let the content respond to the the device.

Signed-off-by: Dan Scott <dan@coffeecode.net>
Responsiveness: specify padding in ems not px
If we work with a relative unit like ems then the design can be more
responsive. In this case, 40px was a huge amount of padding on smaller
screens; use 0.5em padding and increase that on larger displays.

Also, remove the CSS declarations that were made redundant by subsequent
declarations.

Signed-off-by: Dan Scott <dan@coffeecode.net>
Responsiveness: property table display
Allow table elements to display as inline-block elements on smaller screens.

Definitely not perfect, but allows the content to be viewed without pinching
and zooming or scrolling back and forth.

Signed-off-by: Dan Scott <dan@coffeecode.net>
Responsiveness: less whitespace at page start
2em in an h1 is a lot of white space; cut that in half and it works reasonably
well on small and big screens alike.

Signed-off-by: Dan Scott <dan@coffeecode.net>
Responsiveness: add a meta viewport
Also use generally accepted HTML5 html and meta elements, instead of XHTML, to
simplify and avoid potential quirks.

Signed-off-by: Dan Scott <dan@coffeecode.net>
@rvguha

This comment has been minimized.

Contributor

rvguha commented Apr 2, 2018

@dbs

This comment has been minimized.

Contributor

dbs commented Apr 3, 2018

Google's "Mobile-Friendly Test" at https://search.google.com/test/mobile-friendly?id=TacwddyZ3zuudEcsBMGrIQ says "Page is not mobile friendly: This page can be difficult to use on a mobile device" and lists the following major issues:

  • Text too small to read
  • Viewport not set
  • Clickable elements too close together

The branch I offered tackles the worst of these issues via minimal changes to the current schema.org CSS and code.

It's 2018. Having a website that requires zooming & side-to-side scrolling on phones, or that requires manually changing font size on hi-res laptop and desktop screens simply to be legible, stopped being acceptable years ago. And yes, many of us do consult schema.org on phones and hi-res laptop and desktop screens.

@danbri

This comment has been minimized.

Contributor

danbri commented Apr 10, 2018

Thanks for this @dbs ! We do need improvements in this direction. Do you have a test site with this material up on appspot somewhere, or shall I publish a copy from your Github branch?

@danbri

This comment has been minimized.

Contributor

danbri commented Apr 10, 2018

(well I went ahead and posted it at http://responsive-test-200723.appspot.com/Event just to take a look...)

@rvguha

This comment has been minimized.

Contributor

rvguha commented Apr 10, 2018

@danbri

This comment has been minimized.

Contributor

danbri commented Apr 11, 2018

I'm merging this in, but we have a minor conflict with the CSE fixes I've also just merged into master: #1857

The CSE fix puts generic header tags into a dedicated sub-template file which gets included during template processing:

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

@dbs 's fix had a charset declaration in each file, using a different notation:

<meta charset="utf-8">

I'm resolving the conflict in favour of the abovementioned CSE-fix from #1857 for now. Do we have any evidence that the http-equiv notation is any less mobile-friendly? It would be trivial to also add the charset attribute too, but let's not do it without reason.

@dbs

This comment has been minimized.

Contributor

dbs commented Apr 11, 2018

@danbri <meta charset="utf-8"> is HTML5 vs. the older XHTML syntax. Per https://developer.mozilla.org/en-US/docs/Web/HTML/Element/meta:

The element with a charset attribute is a synonym for the pre-HTML5 <meta http-equiv="Content-Type" content="text/html; charset=IANAcharset">, where IANAcharset contains the value of the equivalent charset attribute. This syntax is still allowed, although no longer recommended.

@danbri danbri merged commit 04ef819 into schemaorg:master Apr 11, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

danbri added a commit that referenced this pull request Apr 11, 2018

Using the HTML5 charset syntax, per #1878 discussion.
Resisted the urge to use self-closing tag...
@danbri

This comment has been minimized.

Contributor

danbri commented Apr 11, 2018

@dbs thanks, how '90s of us! I've merged this with the CSE fixes and updated to HTML5. Previously we had most of the site in Polyglot semi-XMLish, but I think that ship has sailed, so I've left this as

<meta charset="utf-8">

rather than

<meta charset="utf-8" />

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment