Advanced HTML/CSS Notes

This is an idea I've had for a while, but I want to see if it interests anyone else before making a request on GitHub.

Basically, I'd like to be able to do a raw-string search on the note body, primarily to find CSS or HTML markup. The current search functionality returns a very small subset of true hits, with an equal amount of false positives mixed in.

A raw string search could be very useful to find certain CSS or HTML stylings, especially if something is deprecated or is nonuniversal to all browsers, and so it would need to be updated in all applicable notes.

One specific example would be to search for all instances of "font-family". This could help someone discover new fonts to use for their own notes, as well as find fonts that aren't universal across computer platforms, and so would need some kind of fallback font.

It would also allow the discovery of new and different techniques for note presentation that other users employ.

Thoughts?

Edit:

Changed forum topic name and category since the initial issue no longer applies.
Will be adding findings below once I've compiled them. Goal will be to update the about:note formatting wiki.

Hmm, checking just now, it seems this was added in issue #1663 but never really documented. If you include a "*" wildcard in your search it will automatically do a string search. This ability is builder only however.

There should probably be mention that wildcards can be used like there is on the /tags page.

Sweet... I didn't even know what I was missing...

I'll update the help:api page though...

Edit:

Also updated help:notes...

BrokenEagle98 said:

Will be adding findings below once I've compiled them. Goal will be to update the about:note formatting wiki.

Godspeed, examples in "Advanced" section are "under construction" for a very long time already. More useful CSS tricks are necessary, like achieving complete background filling via negative margins, disallowing linebreaks, etc. Also summoning @Moonspeaker , @hemoglobin and all other note wizards here if they want to provide some input.

Heck, yes, I could use this kind of string search improvement. I recall several instances in which I tried to find a particular type of CSS formatting that I'd used previously, but for which I couldn't remember the exact syntax. Text searches of the notes, even using the * variable, turned up a bunch of false positives.

I've been surrounding the terms I'm interested in with *'s, e.g. *font-family*, *arial narrow*, etc. Anything more than simple terms like those risks having misses due to no standardization required on how white space gets placed in the HTML/CSS markup, nor the order to which elements appear in that markup. Also of note, searches are case insensitive, so the *arial narrow* search would find "Arial Narrow", "arial narrow", etc.

Here are some initial observations...

Font Family Lists

1. Font names with spaces won't always get rendered if they aren't surrounded by singular quotes.

Example: font-family:'Bauhaus 93';

2. Some notes that I saw with specialized fonts don't have a fallback font. Specifying more than one option will give the browser additional options in case the first entry fails.

Example: font-family:'Bauhaus 93',Impact;

Note: I found the following site that lists many "web-safe" fonts and the percentage of systems they can be found on: http://www.cssfontstack.com/

3. All font lists should end with a generalized font family, i.e. serif, sans-serif, monospace, cursive, fantasy

Example: font-family:'Bauhaus 93',Impact,sans-serif;

Note: How generalized font families look can vary greatly between desktops/laptops and smartphones. The following screenshot shows a side-by-side comparison using the generalized "cursive" font in the upper left and the generalized "monospace" in the lower right.

https://img42.com/jVoyR

However, there is a way to include certain fonts that are expected such as Comic Sans MS (the default for cursive) regardless of browser or platform, but it requires the use of the @ font-face property in the external site CSS page as well as hosting those fonts on the server. More info can be found here: https://css-tricks.com/snippets/css/using-font-face/

Specific Font Family Issues

Besides the above, certain fonts don't render in certain browsers on certain OS's (Firefox on Windows 7), even if the fonts are installed on that system.

I've listed the fonts I've found so far, as well as possible workarounds.

1. Arial Black: Was able to select this font with some slight modifications.

Example: font-family:'Arial Black',Arial,sans-serif;font-weight:900;

2. Arial Narrow: Was unable to select this font. (The font-stretch property is supposed to assist with this, but it is not supported on any major browser)

• Fallback method: font-family:'Arial Narrow',Arial,sans-serif;This doesn't display Arial Narrow if it's unsupported, but at least it won't default to something undesired

• Transform method: font-family: Arial,sans-serif;transform:scalex(0.8);Don't use Arial Narrow with this method as it would make it even narrower then it is if it gets successfully loaded

Note: Both of the above fonts are noted bugs with Firefox.
https://bugzilla.mozilla.org/show_bug.cgi?id=644385

Edit:

Changed the blocks to just "monospace" to emphasize the difference between general font-families.

If we could make a list of the common formatting tricks translators use, we could add CSS classes for them so that e.g. if you want a filled background you could say <span class="bg-fill">blah blah blah</span> instead of messing with negative margins.

Same goes for fonts: if there are common fonts that translators use, it would be better to make CSS classes for them with proper fallback font stacks instead of leaving it up to the translator. So we could tell translators to just use e.g. <span class="font-narrow">blah blah blah</span> and deal with all the font stacking / browser workaround nastiness in the CSS class ourselves.

evazion said:
...

That would be very useful, especially for text-outlines. The CSS code for that is ugly as hell. I'll try to compile a list of the most common stylings over the coming week, focusing on those that are lengthy and could benefit from a class declaration..

The Inspect Element DevTool...

... or why did I not look into this tool a long time ago?!

As the title of this posts suggest, I've recently discovered the power and usefulness of the Inspect Element development tool, especially when it comes to editing notes. I've compiled a tutorial that won't make anyone an Inspect guru, but should hopefully at least show how to use that tool to make creating various new styles with notes easier and faster.

The benefits of using the Inspect tool as opposed to using the note preview are...

• Instant feedback on how various properties/values will affect the look
• (With the preview function, the slight delay in rendering can make it difficult to determine if any changes have occurred)
• Instant feedback on the validity of values
• (The preview function will not let you know if values are valid or not... they will just quietly fail...)
• Autocomplete as you type out either new properties or values
• (It can be difficult remembering the name for every property/value)
• Inspect will let you know exactly which font is being rendered on that browser
• (It's not always clear which font is being rendered when a list of fonts are given, or a general font-family like "cursive" is used)

There are some caveats to using the Inspect tool...

• Danbooru does sanitize the HTML you enter into the Note edit box
• So what you enter may not even make it to the main page's HTML
• This includes stylings possible with Inspect, but not with Danbooru, e.g. background images
• Using the preview function in the note box will update the HTML code in the Inspect tool
• This will provide feedback on what gets sanitized, and what does not
• Therefore, usage of both the preview function and Inspect tool together will give the best results

Tutorial

Without further ado, the following link has the image I compiled the tutorial onto. If you have any feedback, please let me know. Thanks.

https://img42.com/WdmS2

Edit:

Made note of Danbooru's sanitation of HTML as brought up by Type-kun.

Oh man, I wouldn't be able to live without inspect element. If you're doing any work with HTML/CSS, check it out, it will make your life so much easier.

RE: the issue with javascript hiding notes, you can force them to stay visible by setting `.note-body { display: block: !important; }`.

BrokenEagle98 said:

The benefits of using the Inspect tool as opposed to using the note preview are...

That's all true, but one should be aware that notes are sanitized. Some of the unusual tags you use on the notes will be stripped, for others attributes will get removed. Unlike note preview, inspect tool can't cover for that.

Type-kun said:

That's all true, but one should be aware that notes are sanitized. Some of the unusual tags you use on the notes will be stripped, for others attributes will get removed. Unlike note preview, inspect tool can't cover for that.

Thanks, I had made a note of that during my testing, but unfortunately it never made it to my tutorial/post. I went back and updated it, and also included recommendations on using the preview function and Inspect tool together...

I finally gathered all of the note styles together, including their frequency. Note: The following only captures what is used in the "style=" properties.
In other words, it does not capture "size=", "align=", <b>, <i>, <u>, etc...

• Google Drive: Userstyles.json

Not surprisingly, the following properties had the most variety of values (Top 10):

['color', 'background-color', 'text-shadow', 'background', 'font-size', 'font-family', 'padding', 'border', 'filter', 'transform']

Also not surprisingly, the following properties had the most usage (Top 10):

['font-size', 'color', 'background-color', 'padding', 'margin', 'white-space', 'font-family', 'text-shadow', 'font-weight', 'background']

There were also quite a few interesting misspellings that I'll be getting to. My personal favorites were fort-weight and font-wright... (ツ)

Getting back to what evazion said, I noticed quite a few items that could probably be simplified with a class. The biggest contender being text-shadow, due to it's use as an artificial stroke mechanism.

Once I fix all of the mistakes, I'll post a list of contenders for classes, as well as polling the regular translators for feedback on the class list.

These look like a few of the most common things:

• background: black;
• white-space: nowrap;
• font-variant: small-caps;
• text-align: center;
• margin: -4px; padding: 4px;

I notice some things frequently used in combination too, like making a 4koma title that's centered, nowrapped, and large text. It could make sense to have classes for these things as well, so instead of something like `<span class="center nowrap big">Chibi Miku-san</span>`, you could say `<h1 class="title">Chibi Miku-san</h1>` to apply a common set of styles for comic titles.

That's a great point... I hadn't considered property combinations. Unfortunately, I can't think of a good way to programatically check that since that would require keeping track of all combinations, and the resulting data structure would blow up at a polynomial rate... :p

Some other things I've noticed:

• Sometimes people set font sizes in fixed px units. This is non-ideal, if someone changes their browser's default font size then your text won't scale. It's better to use relative units for font sizes (e.g. 200% or 2em).

• Sometimes people set "width: 446px;" to make the note body the same width as the note box. The trouble is note boxes aren't fixed width. They will scale down with the image if your screen is too narrow and you have the "Fit to window size" setting on. This means setting fixed widths can make your note too wide to see on small screens.

• "white-space: nowrap;" can have the same problem, preventing word wrapping can make the note too wide on small screens.

• In embedded notes, it seems people often hyphenate words and add line breaks manually so that the note box doesn't grow too wide. This again has the problem of note boxes scaling down on smaller screens. Line breaks can shift as the note box changes size. Not sure about the best way to deal with this, but one way is to use &shy; to break words with soft hyphens instead. That automatically hyphenates the word when the line is too long, but leaves out the hyphen when not.

Another trend I've seen is the use of webkit or other browser-specific semantics. I'm of the mind that if it's supported on all browsers as of one browser version ago, then they don't need them. They just add to the complexity and clutter in the note HTML text.

Even if it is only supported via webkits, I would say to still not use it, since it's too new and it may not work on all browsers the way intended....

Just a small update, sharing a new discovery similar to the soft hyphen (&shy;) that evazion mentioned earlier.

When using embedded notes, I found it difficult to get the line to wrap when using hyphenation (e.g. when using honorifics) without inserting a space afterward, which made it look alright for the display box text but somewhat awkward in the pop-up box text. After Googling a bit, I tried <wbr> which didn't work, but then I found the zero-width space (ZWSP) character which does. The way to use it is to place the following text between the parentheses in (&#8203;) or (&ZeroWidthSpace;) wherever you want the line to break in the display box text, which for the above case would be after the hyphen "-" mark. So basically it acts as an optional break character, although unfortunately there's no easy to remember shorthand for the ZWSP.

To see the ZWSP in action, check out post #1518991, first panel/rightmost note box and third panel/rightmost note box.

Edit:

• (02-01-2017) Added alias ZeroWidthSpace which can be used instead of #8203

Just wanted to copy this useful tidbit from Evazion (comment #1681748). It was about how to display something similar to Furigana over a word. See the conversation on post #2697885 for more details.

evazion said:

HTML has a <ruby> tag for this purpose. It would be better to use that.

• https://developer.mozilla.org/en-US/docs/Web/HTML/Element/ruby
• https://jsfiddle.net/3L4zszzs/