Search Box in Class List renders one line below where it should

[DanRathbun]

In the left nav column, the "Search:" textbox renders one line below where it should.
It covers up half of the top line of the listing.

Cause full_list.css:50
rule #search has css attributes width: 170px; and padding-right: 24px;

This rule works fine for the div#search in the iframe#search_frame that displays in a popup window, when the main content window is too narrow. (It's a display: none; toggling trick between the two nav divs.)

The div#search (with this wrapping issue) in the Class List is within a separate iframe#nav (although both iframes get loaded from the same document "../class_list.html")

[If you haven't noticed yet, YARD html is generated with multiple elements with the same id names. For example, there are several div#content on the same display page, although two are within iframes.]

We need to specifically target this div#search inside the iframe#nav, ie:

iframe#nav div#search { 
  width: auto; 
  padding-right: 0px;
}

---

[Moved this issue from the sketchup-api-docs project.]

[thomthom]

This stems from the default Yard template? Might be worth filing an issue there as well. A potential fix could benefit all Yard users.

[DanRathbun]

@thomthom: This stems from the default Yard template?

Yes it does, as this http://www.rubydoc.info/gems/yard/ has the same issue,

The stylesheet "full_list.css" is indeed part of the default template, viz:
https://github.com/lsegal/yard/blob/master/templates/default/fulldoc/html/css/full_list.css

And this box does not work as well. (This non-operational situation is a separate issue.)

EDIT: It actually does work. It's not the kind normal search feature (that then displays a results page.)
It's like a "live" RegExp contains filter that filters the listing in the List pane.
If the box was labeled "Filter" I likely would have grasped it's use long ago.

@thomthom: Might be worth filing an issue there as well. A potential fix could benefit all Yard users.

Okay, I'm checking https://github.com/lsegal/yard/issues to see if this has ever been logged.

---

Offtopic (but related):
There is instead (in the default template) a search box up on the right end of the div#main div#header that does take input (ie, shows a results page upon ENTER,) but never finds anything. (Perhaps a search engine plugin is required?) This is a separate feature and is an input#search_box wrapped in a form.search element. So the CSS controlling it, and the other two on the Class Lists are separate and different.

[DanRathbun]

@DanRathbun Offtopic (but related):
There is instead (in the default template) a search box up on the right end of the div#main div#header ...

Loren Segal said, in lsegal/yard#392 (comment):

In any case, the top right search is a rubydoc.info customization, not part of YARD ...

[DanRathbun]

@thomthom: It looks as though @MSP-Greg has been working on this. He tried (JUL 2016) to get Loren to accept a revamped styling of the List pane static header div, but Loren wanted all the changes broken up into separate pull requests. See:
lsegal/yard#1000
... which Greg has withdrawn himself, on 6 JAN 2017.

Looking at one of Greg's pages, (https://msp-greg.github.io/ruby_2_3/Core/index.html) I can see now that the right padding (24px) was likley for a magglass icon (such as Greg has,) but at some point was removed from the default YARD template. Greg puts the "Search" into the input element's placeholder attribute.
I suspect this text was always supposed to be inside the inputbox, and someone (in antiquity) took it out (because of some browser incompatibility,) and just stuck it in front of the input element. This caused the whole thing to wrap down over the listing (ul#full_list,) because the css was never setup to have the caption in front of the box.

I like Greg's solution more than mine! But it requires a change to the erb files, as well to add the placeholder attribute. (And collapse and expand all buttons at the time, nice.)

So, we can wait until Greg resubmits these to YARD master. There are a number of nice fixes, like the scrollbar fix. (It intrudes up into the header now.)

The easiest quickest temporary fix, might be to delete the "Search: " caption from your template.

[MSP-Greg]

Boy, and I was having so much fun trying to build an updated mingw gdbm package for compiling in Ruby trunk (2.5.0). It's failing to compile on one of the tests, which stops the build. Not fun.

I'll have to think about this. I seem to recall that YARD will allow one to add css files, and they're added after the standard files. So that might be a solution; just change the sizing or something similar.

This issue is browser dependent, I don't recall which device/OS/browser it was, but some render it on one line. I noticed it on an iPad, and it just added to the this does not work on a tablet feeling.

Obviously, I've done a bit of work on YARD's c parsing, inheritance chains, attributes, aliases, templates, etc.

After a few PR's to YARD, I decided that what I wanted to do was too large to try and do a PR at a time.

It's a pretty significant rewrite of the template system / js using XMLRequest/AJAX, no jQuery, etc. When one is dealing with libraries like Rails or AWS (with 20k methods), iFrames cause too much reloading, scrolling, etc. For instance, every time the list pane is reloaded, events are (re)attached to every item.

Off topic, hows the font sizing on my site? Some people have had issues, and I've only tested on a few devices. BTW, my templates have code built in for a full width top header box like SU has...

[MSP-Greg]

Sorry, I didn't even notice this was a new repo with the SU plugin code. You're already adding css files.

The easiest quickest temporary fix, might be to delete the "Search: " caption from your template

display: none;

[DanRathbun]

OffTopic

@MSP-Greg: Sorry, I didn't even notice this was a new repo with the SU plugin code.

Yea, this is the custom YARD template repo, the other repo (ruby-api-docs) is one of the outputs generated from this. The other new repo (also generated from this template,) ruby-api-stubs, is the Ruby stubs with the YARD comments.

Thomas figured out a way to use diff to accept documentation changes to the stubs repo, that get written back into the C++ SketchUp API source comments.

[DanRathbun]

display: none;

This will not work because we want the search box. (It works!)

What we don't need is the caption "Search: ".
The caption is not within it's own element.
It is just plain text pasted into the div#search just in front of the input.
The source looks like:

<div id="search">Search: <input type="text"></div>

[MSP-Greg]

Sorry, I didn't look at the html. That was one thing that was quite a bit of discussion back in the start of XML days (allowing text nodes along with element nodes). I've used content before and after, but never tried to change the content with css. Or maybe something like div#search font-size: 0;, div#search input font-size \d\d...

I'll have a look. Think I'm done for the night.

[DanRathbun]

@MSP-Greg

Off topic, hows the font sizing on my site? Some people have had issues, ...

Looks fine at 100% in Comodo Dragon (Chromium) on both my internal 15" and external 25" SD (100ppi) displays.
All ppl with UHD displays need do is hold CTRL and scroll the mouse wheel to make everything bigger.

[DanRathbun]

Hey this seems to work:

div.fixed_header div#search input { 
  position: absolute; 
}

At least the inputbox will not wrap by itself. It will eventually if the List pane is made too thin, but it wraps along with the "Search:" caption.

The nav_wrap class div element needs a minimum width, to prevent the header content from wrapping down into the class listing.

div.nav_wrap {
    min-width: 225px;
}

[MSP-Greg]

@DanRathbun

off topic

Looks fine at 100% in Comodo Dragon (Chromium) on both my internal 15" and external 25" SD (100ppi) displays.

Do both displays allow you to left dock both the LIST and TOC panes? I've tried to make the font sizing just css based, but I may have to do it in script, based on some kind of pixel based ratio of mono-spaced font width and screen width.

All ppl with UHD displays need do is hold CTRL and scroll the mouse wheel to make everything bigger.

I'd prefer to get the css right rather than force users to change the zoom / text settings.

This morning I opened the SU API site on my iPad and it's kind of DOA.

Re yard-t2, I've kind of forgotten many of the changes I've made. I checked the methods list html of SU vs T2. SU has five elements for each method, T2 has three. That's an example of the many 'breaking changes' that I've made to YARD. Loren could never accept those kind of changes, as they might break a lot of people's plugin code, etc.

Conversely, I always run T2 against the YARD trunk branch, so T2 is not very sensitive to the type of changes that are being done (or accepted) to YARD. FWIW, with no changes, T2 runs the 'plugin' YARD uses for it's 'tags' list and doc additions. I did have to muck with the AWS plugin to get it to run.

Long story short, many of the changes of I've made in T2 will not easily port back into YARD.

At present, T2 does what I'd like it to do for my personal use, and it generates the html used on msp-greg.github.io. It's wrapped in a bunch of 'git related' code for that, I just run a single rb file. Depending on how many libraries have been updated, it can take a while...

I'd be happy to let Trimble use T2, but I suspect my time frame for releasing it open source is beyond what Trimble would prefer in terms of finishing the 'new SU API docs' project.

Finally, as long as SU is doc'ing its API, it would be nice if it also doc'd the Ruby versions it was using. Users would have all the docs at one site, rather than one site for SU, and another for Ruby. Gems are beyond the scope...

[DanRathbun]

@MSP-Greg

Offtopic

Do both displays allow you to left dock both the LIST and TOC panes?

No. The 15" display will not show both panes left docked until CTRL+MouseScroll down to 75% (2 clicks of the scroll wheel.) However, the link font size is not changing. On the big wide 25" display, both panes will left dock at 100%. There seems to be a min link text size setting. Links will eventually start to grow in size at around 150%.

I'd be happy to let Trimble use T2, but I suspect my time frame for releasing it open source is beyond what Trimble would prefer in terms of finishing the 'new SU API docs' project.

Oh yea, right now we just want to get the API docs fixed. (Errors corrected, and examples updated.)
Overhauling YARD isn't something we need to do. But, tweeking custom templates and css is fine for now.

This issue is simply about fixing that darned search box in the List header.

Finally, as long as SU is doc'ing its API, it would be nice if it also doc'd the Ruby versions it was using. Users would have all the docs at one site, rather than one site for SU, and another for Ruby.

Also, not related, but already discussed here: SketchUp/ruby-api-docs#32 (comment)
In my local API doc project (which was just to play around learning YARD,) I created stub files for many of the Ruby Core mixin modules and classes, so that these methods would appear in my local SketchUp API docs.

Thomas doesn't want to take this on now. (It is complex, because SketchUp has used 1.8.0, 1.8.5, 1.8.6-p287, 2.0.0-p247, and now 2.2.4-p230, over the various versions, and platforms. And, until SU2014, the Mac and Windows platforms used different Ruby versions. There have been added methods and breaking changes that affected plugins run on earlier SketchUp versions.)

[DanRathbun]

Okay, I just noticed something weird. This "line wrapping bug" is still present in Comodo Dragon which is behind Chrome by four full (major) versions. or more. I am beginning to migrate back to Chrome because of lack of Dragon development , and that Gmail will no longer support Chrome that far behind. Also, I've come to see that Dragon is not much more than an advertising tool for other Comodo products, like GeekBuddy (which I keep having to uninstall.)

Anyway, I noticed that this issue does not occur on Chrome 56.0.2924.87, but still does on Dragon 52.15.25.664. So, it may just be due to a bug in Comodo's build of Chromium.

I also just checked MSIE v11, and it also appears to be a non-issue.

[DanRathbun]

Closing, as this appears to be a Comodo Dragon specific issue (due to Dragon's builds falling way behind the current Chrome build.)