I'm experiencing a weird issue with skrollr - I followed the steps at https://ihatetomatoes.net/how-to-create-a-parallax-scrolling-website/ using just two slides - a background image with a header that fades and then page content. If I have !doctype set, the first slide doesn't go full-height - but works if I just use
I've seen Strange !doctype bug with parallax plugin 'skrollr', but I can't see anywhere where I'm defining an ambiguous height.
The site I'm working on is http://he.dev.binaryitsystems.com/
I got this fixed up by using the more up to date examples in the github repo.
Related
In my project I'm using swiper.js as a slideshow, each slide either contains and image or a html5 video with webvtt captions / subtitles.
On debugging, we noticed that the subtitle position is wrong (too low, cuts off screen) on webkit browsers.
After much debugging it turned out that this css3 rule on the parent div (the swiper-wrapper) makes the vtt position wrongly:
transform: translate3d(-1024px, 0px, 0px)
When you put the video in the first slide, all goes well, since there's no css translate yet.
This seems to be a core webkit issue: default webvtt positioning breaks when using css translation on a parent.
The workaround I found is to add a line positioning in the vtt itself to every subtitle element, like so:
WEBVTT
00:00:02.160 --> 00:00:06.440 line:90%
hello world
00:00:06.560 --> 00:00:11.920 line:90%
testing subtitles
Any sentence without the "line: 90%" part is rendered partly offscreen. It seems this setting forces the webvtt parser / renderer to set itself to the correct position.
QUESTION: did anyone encounter this issue yet and is there any other (easier) workaround for this bug? Adding the "line:" part to all subtitles would be a hell of a job.. unless there's a good editor that can do that stuff in batch.
QUESTION 2: Since this seems to be a webkit vtt parser bug, anyone know where to best report this?
Test setup here: http://orgonemedia.nl/webvtt-bug/
I'm currently debugging some WebVTT files for English captions and other languages too. I'm experiencing a similar problem, although I can't say what is exactly causing it. I'm going to try the line:90% fix you've suggested here.
ANSWER TO YOUR QUESTION 1: Regarding the job of adding it to all the subtitles, you'll be happy to know that's actually pretty easy with the right tool. I use Sublime Text Editor. The way I would do it is use "Find all" to find all the occurrences of -->, then simultaneously edit each of those lines, using the arrow key to navigate across to the right place on the line (since each subtitle out-time is the same number of characters, 12), then type in line:90%
UPDATE:
So I implemented your suggestion, using the method I outlined, and it successfully repositioned my captions.
More details: I was only experiencing the problem of captions being half off the bottom of the video when viewing on an iPad. Oddly enough, viewing the same page on an iPhone, they were positioned correctly without any change. The 90% change still adjusted it up though.
Intriguingly the line:90% code does nothing to adjust caption position when viewing the page on Chrome.
I'm having trouble getting much at all to display on Safari desktop. I think there's something invalid about my file format, but I'm darned if I can find it.
When editing the captions through my video hosting service's caption editor (I'm using JWPlayer), the timecodes show up as being invalid:
Image showing caption editor with invalid warning
Im using the glyphicons Halfings Font via font face. (downloaded with twitter bootstap v3) When y tried to use the unicode for the camera, i cant get it to work... a rectanlgle shows up while other icons do show up.
This code results as expected, displays the trash can:
<span style='font-family: "Glyphicons Halflings"; font-size: 50px;'></span>
but this:
<span style='font-family: "Glyphicons Halflings"; font-size: 50px;'>📷</span>
instead of the displaying the camera, shows a rectangle.
Any help appriciated!
thanks!
Pancho
ok... found the solution! Turns out that in the font files used for bootstrap, the unicodes were changed for some of the icons. I understand they did this because of some issues with browser compatibility.
Here is the list of modfied/new unicodes:
lock - E033
bookmark - E044
camera - E046
fire - E104
bell - E123
wrench - E136
briefcase - E139
paperclip - E142
pushpin - E146
Found this info on a issue on twitter-bootstraps github proyect, check the link for details.
Hope it helps someone...
Pancho
Having a bit of a conundrum with cross-browser compatibility and could use some help.
Our live version linked to below, seems to work perfectly fine on most browsers, including IE9+, but the controls appear hidden in a non-emulated stock out-of-the-box version of IE8:
http://dig-houston.com/portfolio/inspiron
Here's a screenshot of what it looks like in IE8:
At one point, I was still able to slightly see the controls sticking up from the bottom (and click) which lead me to believe something had gone awry in absolute positioning or the rejection of newer CSS techniques. But as my fine tuning progressed and heights were adjusted, I believe the controls were hidden further out of view outside the box.
That being said, I think this is just a CSS issue, but haven't targeted the right styles being applied yet. To anyone else out there using Video.js
I'm having a problem with Twitter Bootstrap Inputs showing correctly on safari 6.0.
Im pretty sure this was fine before I moved to Mountain Lion, and it does seem to be an issue with Chrome.
Basically in Safari, the right end of the input seems cut off an is not displaying correctly. Ive taken a screen shot to demo what I mean...
Safari:
Chrome:
Any ideas?
EDIT: Just looking at the Twitter Bootstrap site and I see that alot of their inputs have the same problem!
Anyone else seeing this?
The artifact appears to be an issue with Safari's rendering of border-radius, and is not specific to Twitter Bootstrap. See rendering borders on Apple's support forum. The inputs usually render normally after you select them.
Disabling border-radius on the affected elements with the following two lines removes the artifact. Be careful though, sometimes this causes even more puzzling artifacts on nearby buttons.
-webkit-border-radius: 0;
border-radius: 0;
When embedding html inside of SVG using the foreignObject tag, webkit based browsers render the backgrounds of the embedded html elements behind the svg elements. See http://code.google.com/p/chromium/issues/detail?id=35545 .
Here's an example : http://www.mxgraph.com/demo/markup/webkitbg.html
The green div should be on top of the red.
Does anyone know of a workaround for this issue? Maybe some incantation of z-index and/or grouping of elements or something in svg to fool webkit into doing the right thing?
This is webkit bug 58417, fixed on 2011-11-10. The fix is in Chromium version 17, which is currently in beta as of 2012-01-09, and should be released in early February. Not sure when the fix will land in Safari, but luckily I don't need to support it.
So the workaround seems to be "wait a month"...
I've just been hit by the same issue. Even though the bug is fixed since a long time in Chrome, Safari seems to be ages behind with the codebase.
My solution is to add style="display:inline-block" to the first child of the foreignObject tag. This seems to fix the problem.