Clojurians
#hoplon
<
2016-06-21
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

micha00:06:45

i think those are not actually elements

micha00:06:54

those are host objects

micha00:06:55

you can still do document.body.appendChild(document.createElement("object")) in the console on ie, right?

jumblerg00:06:24

but i cannot create an object element

jumblerg00:06:45

then call o.apply(o, [null]);

micha00:06:55

because those aren't Element type

micha00:06:06

they're host objects

micha00:06:16

they have no prototype and whatnot

micha00:06:45

they just implement an interface that's similar to the Element one

micha00:06:55

like NodeList vs Array

micha00:06:41

we can just put a guard on those tests for ie8 i suppose

jumblerg00:06:25

so, yeah, can’t call apply on any of those in ie 8

jumblerg00:06:36

that’s one of our issues, anyway

jumblerg00:06:15

@leontalbot: do you use object, applet, or embed anywhere in your code?

jumblerg00:06:40

@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?

jumblerg00:06:31

i have an idea

micha00:06:45

i don't think those are going to be used via hlisp really

jumblerg00:06:12

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)))))

jumblerg00:06:22

at least, provided they don’t call IFn on it later

jumblerg00:06:35

but that will be pretty infrequent

jumblerg00:06:25

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.

micha00:06:53

this implementation looks familiar 🙂

jumblerg00:06:06

oh, probably lol

micha00:06:42

i think it's ok to not support those objects in hlisp probably

micha00:06:06

we could make a thing to work around it if it comes to that

jumblerg00:06:17

we don’t need people embedding flash

jumblerg00:06:25

i guess maybe the thing is pdfs

jumblerg00:06:51

but we could offer maybe a more concrete implementation for those maybe

micha00:06:31

if people are doing those things in ie8 they probably know what they need to do

jumblerg00:06:32

or disallow those as well in favor of the js viewers

micha00:06:45

cause it's pretty complicated in regular jquery i'm sure

micha00:06:06

like they will have a separate ie8 compatible implementation already

micha00:06:14

so i'm sure they can make it work

micha00:06:28

you can still create a thing and then append it to a div

jumblerg00:06:35

does it make sense to remove those three constructors altogether?

micha00:06:52

they work in html5 browsers though

jumblerg00:06:29

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?

micha00:06:54

i dunno, but they should be supported if possible

jumblerg00:06:06

don’t work in the past, don’t work in the future...

micha00:06:09

ie8 it looks like it would be possible, but require some polyfill

micha00:06:22

the tests pass in chrome

jumblerg00:06:42

i’m sure we can make them work in ie 8, but if someone really needs them, they can (.createElement “object”)

micha00:06:05

so i wouldn't remove them from hoplon.core

micha00:06:20

they're not hurting anything by being there

jumblerg00:06:17

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.

jumblerg01:06:10

it seems like a less-than-ideal path to start heading down… adding exceptions for things.

jumblerg01:06:16

but if you prefer, i can throw in an ie 8 warning instead.

micha01:06:38

i mean the correct thing would be to make the polyfill

jumblerg01:06:50

right. but… work.

micha01:06:08

right so in the meantime i would just let those not work in ie8

jumblerg01:06:18

my sense is to make things smaller instead. ok.

micha01:06:21

a warning would be nice to have

micha01:06:31

we can't remove valid html5 things

jumblerg01:06:46

yeah, i guess the other principle is to have full html5 support.

micha01:06:52

that's a decision to make at a higher level, the framework level

jumblerg01:06:37

incidentally, in the interest of printing a warning if is-ie8, might be nice to support console.log too...

jumblerg01:06:03

there’s a var console = console || { log: function() {} }; hack for this

micha01:06:22

yeah that's a tricky thing to do though

micha01:06:35

because that interferes with other polyfills

jumblerg01:06:36

anything that writes to console breaks everything in ie 8

micha01:06:42

you could use the goog logger

jumblerg01:06:44

which is why dev tools break

micha01:06:00

yeah but applying the polyfill would break any other polyfill the user is using

micha01:06:31

we want to avoid messing around with global objects we don't own basically

micha01:06:58

pulling in the goog logger for that would add bloat we don't need

micha01:06:44

if you want to run dev in ie8 you'd want to add that yourself

jumblerg01:06:10

well, this has been a fun use of an evening

micha01:06:22

haha how are you using ie8?

micha01:06:28

do you have a vm?

jumblerg01:06:38

i signed up for SauceLabs last week

jumblerg01:06:54

they have an opensource program

jumblerg01:06:05

except, they time the damn vm out after ten mins

jumblerg01:06:01

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.

jumblerg01:06:20

basically, they support open source by encouraging you to pay them to support open source.

micha01:06:51

that sounds like a plan lol

micha01:06:03

yeah i remember how terrible the dev tools on ie8 were

micha01:06:27

i think they have a debugger that is okay on that thing

micha01:06:42

like the only way to see things is to step through code or something

jumblerg01:06:43

it works, once you figure it out

jumblerg01:06:51

at any rate, now we have a baseline app for testing courtesy of thedavidmeister and a bit of head->wall banging

micha01:06:11

i will look into some kind of cross browser testing hookup

jumblerg01:06:26

yeah, i think that’s what the SauceLabs thing is for

micha01:06:27

to do the unit tests in different browsers

jumblerg01:06:37

i’ll add you to the hoplon os account

micha01:06:51

sweet, maybe we can have travis send off a thing

micha01:06:54

or something

jumblerg01:06:00

yeah, that’s what i’m working on

micha01:06:29

awesome that will make things more stable i think

jumblerg01:06:49

i need this for ui as well

jumblerg01:06:30

there are two many hierarchies of mutually exclusive scenarios to traverse manually without it

leontalbot01:06:11

@leontalbot "use object, applet, or embed" no I don't think so

leontalbot01:06:24

You tell me when I can test 🙂

leontalbot01:06:32

I am thankful for all the trouble this makes 🙂

jumblerg01:06:27

yeah, man, i think i had convinced micha to dump ie 8 before you showed up to the party 🙂

jumblerg01:06:53

but ie 8 support isn’t a bad thing to have, i think it is a plus for my customers as well

jumblerg01:06:51

people still use it, so i think it is part of having a mature. “enterprise-grade” platform to build on

jumblerg01:06:51

it is a plus for hoplon that we can support it

jumblerg01:06:04

if we get in right in the foundational hoplon layer, then all the stuff in ui should work with it as well.

alandipert02:06:21

Did ie8 not work and now it does?

alandipert02:06:01

If so that's pretty awesome, we can cut a release and make announcement

alandipert02:06:20

And in our next release we can support ie7 😉 👍 😞

jumblerg02:06:13

it is getting incrementally closer to working, yeah

jumblerg02:06:17

and by "we", i think we mean "you" can support ie 7.

micha02:06:27

ie 7 is bananas

jumblerg02:06:33

yeah. don't get any ideas.

jumblerg08:06:40

@leontalbot: give master a test drive when you get a chance. the ie 8 support is much more comprehensive now.

leontalbot13:06:19

@jumblerg: hmm, on opt simple, with standard IE8 I still get hoplonKids=[object Object]

leontalbot13:06:07

html5 tags like <footer> work

jumblerg14:06:11

@leontalbot: the hoplonKids tag with object is expected behavior, and a consequence of hoplon's implementation

micha15:06:48

@jumblerg: why is that tag showing up?

micha15:06:06

seems strange to me

micha15:06:15

that should be a property of the object, not an attribute

jumblerg15:06:46

@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.

jumblerg15:06:14

it is one of several that show up, actually

micha15:06:30

seems harmless enough

jumblerg15:06:38

doesn't seem to impact function of the thing

micha15:06:52

yeah i guess in ie8 properties and attributes are the same thing

micha15:06:12

i wonder why they moved away from that

micha15:06:16

maybe perf issues

jumblerg15:06:29

@leontalbot: on my phone, can you paste elements other than head and body?

jumblerg15:06:12

the children should have more properties on them than just the hoplon kids atom

jumblerg15:06:24

@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

jumblerg15:06:46

added a few as well

jumblerg15:06:40

put metadata on experimental ones to align it hoplon 6 with the current version of that page

jumblerg15:06:21

was also thinking we could put the browser support data for each elem ctor on the var metadata

jumblerg15:06:42

which could make tooling smarter

jumblerg15:06:18

maybe pass min browser versions to boot-hoplon

micha15:06:18

i donn't think we want to remove deprecated things

jumblerg15:06:26

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.

micha15:06:28

because they're still valid, just deprecated

micha15:06:47

basically i don't think we want to get fancy with it

jumblerg15:06:51

but if someone is building an app today on hoplon 6

jumblerg15:06:24

they should never use them

micha15:06:33

well that's their decision

jumblerg15:06:37

and we haven't released yet

jumblerg15:06:49

also, it makes sense technically

micha15:06:04

it's getting more complicated than it needs to be

jumblerg15:06:06

since it eliminates several corner cases

jumblerg15:06:30

this makes things simpler

jumblerg15:06:56

chrome is actually removing some of these in future versions

micha15:06:09

so in future versions we can remove them from hoplon too

micha15:06:21

years from now lol

jumblerg15:06:49

elements like applet are the ones that break in ie 8

jumblerg15:06:59

also depricated

micha15:06:19

i think a note about that in the docstring would be fine

jumblerg15:06:35

it makes little sense to me to add deprecated elements to something being released today

micha15:06:45

why, deprecation doesn't mean removal

jumblerg15:06:16

yeah, but nobody should be using them in a new thing

micha15:06:23

the place to make those decisions is at the framework layer

jumblerg15:06:26

it future proofs hoplon

micha15:06:42

i don't want to decide what people should or should not be doing though

jumblerg15:06:46

and it makes it more stable backward as well

micha15:06:51

i don't know their problems

micha15:06:06

that's too opinionated for me

jumblerg15:06:12

you aren't, the w3c browser vendors are

micha15:06:24

well when they remove support that's a different thing

jumblerg15:06:26

i often disagree with their opinions too

micha15:06:47

if it's still supported in the browser i don't see why we wouldn't want to support it

micha15:06:05

i don't see what the cost is

jumblerg15:06:45

because we're exposing more api surface area than necessary, and parts of the surface where things go sideways anyway

jumblerg15:06:08

not supported in ie 8

micha15:06:18

so a note in the docstring about that is fine

jumblerg15:06:55

if someone needs that stuff, for some ingodly reason, the can call createElement themselves

micha15:06:04

it's fine to have a few rough edges with ie8 support, especially for things like applet and object etc

jumblerg15:06:31

but why introduce a rough edge into a new thing?

micha15:06:32

if you're making a thing that needs to work in ie8 you're already going to be polyfilling tons of stuff

micha15:06:54

because it's wrong to not support things that are supported in html5 browsers

micha15:06:08

making that kind of decision is too opinionated

jumblerg15:06:16

these are the things that are officially removed from html

micha15:06:40

basically the union of things supported by browsers ie8+ we should support

micha15:06:57

some won't work on some browsers

micha15:06:18

but the framework layer can decide whether to restrict those or whatever

micha15:06:47

i don't want to get into the business of devising a universal browser

jumblerg15:06:48

we also had obsolete elements in that list

jumblerg15:06:22

my thinking was we just follow the mozilla element list/spec

micha15:06:51

yeah i mean it should be the union of things suppoted by the browsers currently in use in the world

micha15:06:08

with html5 as the standard

micha15:06:25

i gues whatever is html5 supported is fine

micha15:06:01

but we should include deprecated things i think

micha15:06:08

if things have been removed then we could remove them from hoplon to

jumblerg15:06:25

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.

jumblerg15:06:36

but i've said my piece :)

micha15:06:57

if they weren't going to support it then they would have removed it and not just deprecated it

jumblerg15:06:05

thoughts on metadata annotations for this stuff?

micha15:06:59

you know what, fuckit, we can remove deprecated things if you want lol

jumblerg15:06:02

i think the rationale for depreciation is to not immediately cut off ppl who have already built things

jumblerg15:06:37

like a lane closing sign in the interstate

micha15:06:44

well there may be valid reasons to use the deprecated parts of the API

leontalbot15:06:24

@jumblerg: sure

mynomoto15:06:47

Could the ie8 stuff be extracted to a library? I don't use them myself but people could just add that if possible.

jumblerg15:06:58

not sure how to handle experimental things

micha15:06:42

perhaps a namespace for experimental things?

jumblerg15:06:01

namespaces make sense

jumblerg15:06:51

biz mtg, bbiab

jouerose17:06:27

hummm glad to be back here

jouerose17:06:32

hope you are all well

jouerose17:06:07

does anyone often use the function "comp" ?

micha17:06:40

all the time, welacome back!

jouerose17:06:30

micha: thanks

micha18:06:39

comp, partial, juxt, apply

micha18:06:04

those are the 4 awesome things, i want to get a tattoo of them