This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (2)
- # aws-lambda (2)
- # beginners (26)
- # boot (179)
- # cider (36)
- # cljs-dev (118)
- # cljsrn (23)
- # clojure (150)
- # clojure-android (1)
- # clojure-austin (7)
- # clojure-austria (3)
- # clojure-canada (1)
- # clojure-dev (7)
- # clojure-dusseldorf (4)
- # clojure-germany (3)
- # clojure-greece (34)
- # clojure-nl (4)
- # clojure-quebec (9)
- # clojure-russia (30)
- # clojure-spec (38)
- # clojure-uk (3)
- # clojurescript (46)
- # clr (1)
- # core-async (2)
- # css (2)
- # cursive (17)
- # datomic (12)
- # devcards (8)
- # dirac (1)
- # docker (2)
- # hoplon (216)
- # jobs (2)
- # kekkonen (1)
- # lein-figwheel (18)
- # leiningen (2)
- # luminus (1)
- # mount (4)
- # off-topic (2)
- # om (15)
- # onyx (1)
- # parinfer (1)
- # pedestal (2)
- # planck (26)
- # reagent (98)
- # spacemacs (6)
- # specter (19)
- # spirituality-ethics (54)
- # untangled (22)
- # vim (24)
- # yada (4)
you can still do
document.body.appendChild(document.createElement("object")) in the console on ie, right?
@micha: then do what? does hoplon abandon ie 8 support for host objects? or do we go to the trouble to implement them correctly in ie by not going through IFn?
gotit by modifying the constructor
(defn- make-elem-ctor [tag] (fn [& args] (let [[attrs kids] (parse-args args) elem (ensure-kids! (.createElement js/document tag))] (doto elem (add-attributes! attrs) (add-children! kids)))))
of course, the moment i try to pass attributes or children to them they break again since the ICustomElement functions are first implemented on the prototype.
they’re slowly going away i think anyway for security reasons, does anyone use them for anything other than java applets, flash, and pdf? what are the other cases?
i’m sure we can make them work in ie 8, but if someone really needs them, they can (.createElement “object”)
as a matter of principle, my sense is that if we’re supporting ie 8 and up, everything in core should work everywhere. if someone really needs object element, they can roll their own.
it seems like a less-than-ideal path to start heading down… adding exceptions for things.
incidentally, in the interest of printing a warning if
is-ie8, might be nice to support console.log too...
and when you factor in the latency of the remote connection and awkward dev tools in ie, that’s just enough time to build up a build up some of the state you need to do something useful in the console, but not enough to do anything useful, before they pull the plug on you.
basically, they support open source by encouraging you to pay them to support open source.
at any rate, now we have a baseline app for testing courtesy of thedavidmeister and a bit of head->wall banging
there are two many hierarchies of mutually exclusive scenarios to traverse manually without it
yeah, man, i think i had convinced micha to dump ie 8 before you showed up to the party 🙂
but ie 8 support isn’t a bad thing to have, i think it is a plus for my customers as well
people still use it, so i think it is part of having a mature. “enterprise-grade” platform to build on
if we get in right in the foundational hoplon layer, then all the stuff in ui should work with it as well.
@leontalbot: give master a test drive when you get a chance. the ie 8 support is much more comprehensive now.
@jumblerg: hmm, on opt simple, with standard IE8 I still get
@leontalbot: the hoplonKids tag with object is expected behavior, and a consequence of hoplon's implementation
@micha: my assumption was that it's a function of how the ie 8 tooling element vis is implemented. it doesn't appear in any other browser.
@micha: also went through all the elements last night, removed all the obsolete and deprecated elements on a separate branch based on https://developer.mozilla.org/en-US/docs/Web/HTML/Element
put metadata on experimental ones to align it hoplon 6 with the current version of that page
was also thinking we could put the browser support data for each elem ctor on the var metadata
this metadata would need to depart from the moz spec a bit for certain ctors because createElement lets is add some that aren't officially supported.
it makes little sense to me to add deprecated elements to something being released today
because we're exposing more api surface area than necessary, and parts of the surface where things go sideways anyway
if someone needs that stuff, for some ingodly reason, the can call createElement themselves
it's fine to have a few rough edges with ie8 support, especially for things like applet and object etc
if you're making a thing that needs to work in ie8 you're already going to be polyfilling tons of stuff
yeah i mean it should be the union of things suppoted by the browsers currently in use in the world
my instinct is to not put things out there on something we're releasing today that the browser ppl have told us won't works tomorrow.
if they weren't going to support it then they would have removed it and not just deprecated it
i think the rationale for depreciation is to not immediately cut off ppl who have already built things
Could the ie8 stuff be extracted to a library? I don't use them myself but people could just add that if possible.