What is Endings' stance on browser support/defn of "modern browser"?

[joeytakeda]

Hi there,

I'm developing a site in compliance with Endings standards, but IE11 messes it up horrendously, since I'm using CSS properties that, while available in every other modern browser (FF, Chrome, Edge, Safari, Opera), aren't compatible with IE11 and below (incl. CSS variables, calc(), et cetera). Parts of the JS aren't compatible either (like eventListeners, et cetera) without forking and testing for browsers. Rather than spending time accommodating IE, I simply treat the browser as if JS was disabled if it doesn't play nice with the (compliant) JS I've written. And as per Endings principles, the site then fails gracefully as if the JS never existed. But the CSS is more annoying, since the workarounds aren't so simple; for instance, I would need to have a fallback for every instance of a variable, which eliminates the utility of CSS variables and bloats the CSS.

So my questions here are:

• What is the Endings' definition of a modern browser?
• How should an Endings project handle "non-modern browsers" according to the above definition?

Thanks!

[martindholmes]

Endings projects (and in fact all HCMC projects) care only about modern browsers, and IE (any version) is not one. We actively want things to fail on that browser so that anyone still using it gets another little nudge to move on. We try to write standards-compliant code and test on all current versions of current browsers, but even if something fails (gracefully) on a current browser because it hasn't quite yet caught up with the standard, that's fine.

If you have users or (worse) project members still using IE, do them a favour and explain that even Microsoft strongly recommends that no-one use it any more. Go out of your way not to support it, for the good of the web. :-)

[joeytakeda]

That sounds right to me, @martindholmes. (Luckily, no one on the project uses IE, so no convincing necessary :-). I suppose if a site is built according to Endings principles that if JS and CSS fail, the site is still more-or-less usable, then this isn't much of an issue. I'll probably make a page for the site that explains what browsers we support etc and link it in the footer so that if a user suspects that the site isn't working right, then they can see why.

Should this be a formalized principle in the principles document (and, perhaps of note, that document doesn't exist on the actual Endings site; should it?)

[martindholmes]

The formalized principles say that we support web standards (XHTML5, CSS, JavaScript). We don't support or not support browsers in any formal sense. It's the browser's job to implement the standards. IMHO, no site these days should have any page that mentions specific browsers and what may or may not work with them. If you use a crappy browser, you get a crappy experience, and that's your fault (and that of the browser maker if it's a current version) for choosing that browser. But things should still basically work (unless they're utterly JS-dependent things, such as tiled maps).

The principles should be on the website, but for that to happen they need to be encoded and then rendered and then pushed automatically into the github.io site, which is something I haven't had time to do. If you have time, please go ahead.

[joeytakeda]

@martindholmes @jmhuculak I'm citing the principles in a paper I'm writing re: MoEML at Congress, so I've gone ahead and encoded them into the Github pages thing: https://projectendings.github.io/principles/

Note that I haven't linked it anywhere, so it should might need to go in the nav bar or something like that.

Annoyingly, I can't put the leading numerals in the section numbers, since the Jekyll template auto-generates ids based off of the heading text, so something like:

## 1. Data

Creates an id of:

<h2 id="1-data">

which is invalid, of course.

Anyway, they are up there now; didn't change anything other than the capitalization of the headers. Let me know if you want anything changed.

[martindholmes]

Thanks Joey. We do need this page, but the limitations here are yet another indication that we have to get the website onto the UVic server where it belongs, and get proper control over it.

[jmhuculak]

Awesome, Joey. And good timing. I'm presenting on the project on Tuesday. Are there any other additions coming down the pipe between now and Sun? Great work!!!

[joeytakeda]

I don't have any plans of changing any of that content, so it should be stable, unless someone notices a typo or something :-).

[joeytakeda]

And now closing this issue, since the main issue has been resolved as has the tangential one

[jmhuculak]

Just occurred to me: one of the other major themes of the interviews was "institutional responsibility" (which I'm also presenting on at Congress). I'm wondering if that deserves its own section heading in our principles?

[clcarlin]

Institutional responsibility is important but do we want to include in the principles matters beyond the researcher's control? Or is the principle the researcher's responsibility to communicate with the institution about support?

The question of whether or not Endings principles should include/apply to the institutions themselves is an interesting one that I think we should discuss at the June 24 workshop.

From: Matt Huculak notifications@github.com<mailto:notifications@github.com> Reply-To: projectEndings/Endings reply@reply.github.com<mailto:reply@reply.github.com> Date: Sunday, June 2, 2019 at 11:19 PM To: projectEndings/Endings Endings@noreply.github.com<mailto:Endings@noreply.github.com> Cc: Subscribed subscribed@noreply.github.com<mailto:subscribed@noreply.github.com> Subject: Re: [projectEndings/Endings] What is Endings' stance on browser support/defn of "modern browser"? (#3)

Just occurred to me: one of the other major themes of the interviews was "institutional responsibility" (which I'm also presenting on at Congress). I'm wondering if that deserves its own section heading in our principles?

- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/projectEndings/Endings/issues/3?email_source=notifications&email_token=AEOA7ND7SRA7KKRJY5FAES3PYSZV7A5CNFSM4HCR4GYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWYNCXY#issuecomment-498127199, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AEOA7NGBHJLOYYJTECJRPALPYSZV7ANCNFSM4HCR4GYA.

[martindholmes]

I think the point about institutional responsibility is that you cannot rely on it. Sure, you SHOULD deposit your stuff with your institutional library, but you shouldn't depend on them to a) continue to exist, and b) continue to have policies which are benign with regard to long-term preservation of digital projects. You should find as many other locations as you can to deposit your stuff too.

[jmhuculak]

Indeed! I suppose what I'm getting at is what martin points to: "Deposit". I think one of the goals of the project is to provide frameworks so that users CAN approach librarians/archivists in order to get a long-term commitment for the "product" (NOT the website)--as well as a strategic plan for other locations. I do think a section on "deposit" (in all its forms) would be really useful to get people thinking about those long-term commitments before they run out of money. Thoughts?

[martindholmes]

In most of our cases, the website is the product. Good website products automatically encompass the source data (XML etc.), so archiving the website and all its components constitutes archiving the whole (with the exception of the history which is encapsulated in the version-control system, of course -- perhaps we should look at ways of preserving that too?).

But I like this word Deposit. It's an action rather than a component such as Data, Processing etc., so it doesn't fit with the principles document, but maybe it belongs in a separate document called "Actions"?

[jmhuculak]

Indeed! And I think Principles will be universal, so I like keeping them the way they are. I love the idea of creating a separate page called "Actions," which would give folks examples of how they can put "principles" into "action." This will change over time, of course, but I think it will be useful for the entire community.

[JanelleJenstad]

We made a checklist for the course, and the people in the course should go away with a bunch of “to-do” lists. We could convert these into a robust set of “action items” to publish on the Endings website later.

J.

Janelle Jenstad, Associate Professor, Department of English Director, The Map of Early Modern London; PI, Linked Early Modern Drama Online Associate Coordinating Editor, Digital Renaissance Editions Managing Editor, Scenehttps://uvic.ca/scene University of Victoria Skype: janelle.jenstad; Time zone: UTC -8http://www.timeanddate.com/worldclock/canada/victoria jenstad@uvic.ca

From: Matt Huculak notifications@github.com Sent: June 6, 2019 11:33 AM To: projectEndings/Endings Endings@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: Re: [projectEndings/Endings] What is Endings' stance on browser support/defn of "modern browser"? (#3)

Indeed! And I think Principles will be universal, so I like keeping them the way they are. I love the idea of creating a separate page called "Actions," which would give folks examples of how they can put "principles" into "action." This will change over time, of course, but I think it will be useful for the entire community.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/projectEndings/Endings/issues/3?email_source=notifications&email_token=ABNLCOEASRLAAJERH6QCNZTPZFJ5JA5CNFSM4HCR4GYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODXDYFSQ#issuecomment-499614410, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ABNLCOHKNTGBLXQBHEKBH4TPZFJ5JANCNFSM4HCR4GYA.