While practicing different scenarios in which CSS3 pseudo-classes and selectors might come in handy, I ran across something I just can't figure out!
Here's the situation. I want to modify the :first-of-type::first-letter of the first non-empty paragraph for a block of text. I'm not sure that pseudo-classes can be stacked though. Here's what I've come up with (Doesn't work, of course)
.article-body > p:not(:empty):first-of-type::first-letter { ... }
Given the following markup:
<div class="article-body">
<p></p>
<p>The "T" in this paragraph should be the one affected.</p>
</div>
The only guess I can come up with is that pseudo-classes (ie; :not() and :first-of-type) can not be stacked upon each other. Which is odd since you can stack pseudo-elements upon each other, and other pseudo-classes...
Any ideas for how this can be accomplished?
:first-of-type selects the first p, as the name suggests, not the first non-empty p as you might want.
They stack just fine, but :first-of-type purely operates on the tag (i.e. type), not on the preceding complex selector. So you just end up looking for the first p, and that first paragraph also shouldn't be empty. And that doesn't exist.
Assuming empty paragraphs might appear throughout the text, and you only want the first, non-empty paragraph to be affected, I don't think it's possible to do this with just one selector. This is the best I can come up with:
p:first-of-type::first-letter,
p:empty + p::first-letter { text-transform: uppercase; /* ... */ }
p:not(:empty) ~ p::first-letter { text-transform: inherit; /* reset */ }
That will apply the CSS only to the first non-empty paragraph (well, and to a first empty paragraph, but it won't do anything then anyway).
Removing the empty paragraph causes
.article-body > p:first-of-type::first-letter { ... }
to behave properly. Is there any reason that the empty paragraph needs to be there? Can you alter the spacing of the first paragraph to account for the empty one not being there?
Related
Below is a picture of my current accessibility tree. You can see that the 4 text leaves in it are separated, but it still forms only one line of content. Is this still accessible well ("well" meaning screen readers can detect that they form one complete sentence), or should all of the text leaves be combined into one leaf?
If they should be combined, how can you concatenate variables into the text in React, while keeping it as one single leaf? This is my current code: <p>{cloudiness}% ({cloudinessDescription})</p>
How they are read aloud depends on the screen reader being used. VoiceOver reads it as one phrase, but that doesn't mean others will. Having it split up wouldn't be a nice experience, but it doesn't mean it's not accessible.
If you really want to make sure it's read as one phrase but don't like the noise of the template literal inside the JSX (I agree), why not define the string somewhere else until you are able to test on multiple screen readers?
const cloudinessSummary = `${cloudiness}% (${cloudinessDescription})`;
return <p>{cloudinessSummary}</p>;
In the screenshot of the DOM you can see that the text ending in the numbers 623 is given a x value of 160. However, when I inspect the text, something something which is rendered before the numbers it has a length of 126.08px (see the second screenshot). This means that my text, which I translated 160px to the right, is not actually 160px to the right. From this article, I understand that unless a viewport is provided one user unit should equal one screen unit, but this is obviously not the case here. Why is this? Thanks! I'm using React if that is necessary.
You're setting "text-anchor' to "end' which will end up shifting the text to the left. Set it to 'start' (or possibly skip it altogether) and you should see the behavior you expect.
I need your help.
Now I am using AsciiDoc and AsciiDoctor to create some manuals.
I want texts smaller on some specific blocks, for example wide table, wide list, and so on, but not want main texts smaller.
Especially I need to make texts of wide tables smaller as my customer requests so.
Is there any way?
You mention lists and tables...
About lists, it can't be done as stated in AsciiDoctor Documentation:
Unsupported
Complex AsciiDoc markup is not permitted in attribute values, such as:
lists
multiple paragraphs
other whitespace-dependent markup types
As you can see, there it mentions multiple paragraphs, so while #EhmKah answer is a correct way to set a custom styling block, it won't be rendered as expected in a table/list as it's multi-paragraph.
The Built-in CSS class syntax is the way to go [small]#any phrases#
But in order to make this work in a table, you must set the cell type with a specifier in this case, the AsciiDoc specifier denoted by a
This means the cell (or column) will render supported AsciiDoc statements, attributes, etc.
Here's a working example:
[frame="none",grid="none"]
|====
a| image::images\logo.png[] a|[.small]#Autor: {author}#
|====
If you have tons of rows/columns, you don't have to manually apply the a to all of them. You can set the columns you need this behavior this way:
[cols="1a,2a",frame="none",grid="none"]
|====
| image::images\logo.png[] |[.small]#Autor: {author}#
|====
You can check its documentation for more about Column Formatting and you can check the Rendered table with variable widths and alignments sub section for more about AsciiDoc (a) and other specifiers.
docinfo.html + --attribute docinfo=shared
You can drop your CSS modifications into a file called docinfo.html:
<style>
/* Your custom CSS. */
</style>
and then build with:
asciidoctor --attribute docinfo=shared README.adoc
and that makes Asciidoctor 2.0.10 place docinfo.html at the bottom of the <head> element.
So you can override most of the default Asciidoctor style from there.
Then it's just a matter of understanding the generated HTML and previous style definitions to override them.
For image specifically, see also: How to set a custom image height for an image in Asciidoctor?
When you use a theme file, you can add a role to it like this:
role:
mycustomfont:
font-color: #333
font-size: 10
Now you can reference your newly created role right from your table cell:
a|[.mycustomfont]# some text #
I read something about
[small] and [%autofit] option https://github.com/asciidoctor/asciidoctor-pdf/issues/185 I never needed it so maybe you give it a try.
example-code
[small]
----
should be rendered in smaller font.
----
[%autofit]
----
really long text that doesn't want to fit on a single line with the default font size, so we'll make it shrink to fit.
----
It is well known how to obtain a TODO list in Doxygen, typing:
\todo Item one
\todo Item two
and so on, but when something has been done, how to keep track of this?
If I have done item two I don't want to remove it, I want to mark it as done:
\todo Item ono
\done Item two
How do I do this?
I dug around in the Doxygen documentation and stumbled over the \xrefitem. It's supposed to be:
A generalization of commands such as \todo and \bug. It can be used to
create user-defined text sections which are automatically
cross-referenced between the place of occurrence and a related page,
which will be generated. On the related page all sections of the same
type will be collected.
The first argument is an identifier uniquely representing the
type of the section. The second argument is a quoted string
representing the heading of the section under which text passed as the
fourth argument is put. The third argument (list title) is used as the
title for the related page containing all items with the same key. The
keys "todo", "test", "bug" and "deprecated" are predefined.
So you could specify a new alias, e.g. "done" in your Doxyfile:
ALIASES += "done=\xrefitem done \"Implemented TODOs\" \"Implemented
TODOs\" "
And in your code you should be able to use the new "done" tag like all the others:
/// \done fixed broken function
According to the doxygen manual there is no such "inverse" of the \todo command. Perhaps you can just keep the \todo and mark it manually as done, somehow.
Unfortunately doxygen's Markdown doesn't seem to support strikethrough (unlike Stack Overflow's, obviously), that would otherwise have been a good and common choice. Perhaps you can set it up using custom styling and spans.
I have to accomodate an MREC advertisement in my layout. The ad is 300pixels wide, and cannot resize as the fluid grid otherwise contracts.
Further, the ad needs to be the first item on smartphone, before the headline block. So, on the breakpoint I am setting it to omega to push it "after" the headline, as in this screenshot (gray rules just to make it easier to see).
The headline is 8 cols, the ad is 4. All is fine except on ipad the ad column and the ad reduces to under 300 pixels, which we are not allowed to do. So, how to keep everything fluid except the ad container?
Set max/min widths on the container?
This is not hard to do, but it means the grid up top won't exactly match the flexible grid below. I assume that isn't an issue. You have to use some functions to lay out these two elements, but everything else can be done exactly as it was before.
You can keep the ad flexible down to a minimum width:
.ad {
#include span-columns(4 omega);
min-width: 300px; // you can use any width you want.
}
Or you can make the ad completely static:
.ad {
float: right;
width: columns-width(4); // you can use any width you want.
}
The important part is that you must not set a column width on the headline.
You have a few other options. The simplest might be to set right margins and padding equal to the static ad size (plus gutter):
.headline {
margin-right: columns-width(4) + $gutter-width;
}
Or, if you want that gutter to flex, try:
.headline {
margin-right: columns-width(4);
padding-right: gutter();
}
You can add clear: both; to the main content to make sure it clears the headline and ad.
If this approach doesn't work for you, try creating a new "formatting context" for the headline. One of the classic techniques is simply overflow: hidden;. Nicole Sullivan has a good blog post on how they do it for oocss, but it gets a bit more complex and you may not need all that.
UPDATE:
All these solutions require the ad coming first in the markup. The only way around that is if you know the height of the ad. In that case, you could position the ad absolutely rather than floating it, create space for it in the same way, and set a min-height on the headline (or row-container if you have one).