Change warnings from blockquotes to divs

Author: Havvy

src/expressions/method-call-expr.md

@@ -81,13 +81,17 @@ generic methods or traits are considered the same, then it is a compiler
 error. These cases require a [disambiguating function call syntax] for method
 and function invocation.
 
-> Warning: For [trait objects], if there is an inherent method of the same name
-> as a trait method, it will give a compiler error when trying to call the
-> method in a method call expression. Instead, you can call the method using
-> [disambiguating function call syntax], in which case it calls the trait
-> method, not the inherent method. There is no way to call the inherent method.
-> Just don't define inherent methods on trait objects with the same name a trait
-> method and you'll be fine.
+<div class="warning">
+
+***Warning:*** For [trait objects], if there is an inherent method of the same
+name as a trait method, it will give a compiler error when trying to call the
+method in a method call expression. Instead, you can call the method using
+[disambiguating function call syntax], in which case it calls the trait
+method, not the inherent method. There is no way to call the inherent method.
+Just don't define inherent methods on trait objects with the same name a trait
+method and you'll be fine.
+
+</div>
 
 [IDENTIFIER]: identifiers.html
 [visible]: visibility-and-privacy.html

src/type-layout.md

@@ -233,13 +233,17 @@ the default `enum` size and alignment for the target platform's C ABI.
 > really a "best guess". In particular, this may be incorrect when the C code
 > of interest is compiled with certain flags.
 
-> Warning: There are crucial differences between an `enum` in the C language and
-> Rust's C-like enumerations with this representation. An `enum` in  C is
-> mostly a `typedef` plus some named constants; in other words, an object of an
-> `enum` type can hold any integer value. For example, this is often used for
-> bitflags in `C`. In contrast, Rust’s C-like enumerations can only legally hold
-> the discriminant values, everything else is undefined behaviour. Therefore,
-> using a C-like enumeration in FFI to model a C `enum` is often wrong.
+<div class="warning">
+
+Warning: There are crucial differences between an `enum` in the C language and
+Rust's C-like enumerations with this representation. An `enum` in  C is
+mostly a `typedef` plus some named constants; in other words, an object of an
+`enum` type can hold any integer value. For example, this is often used for
+bitflags in `C`. In contrast, Rust’s C-like enumerations can only legally hold
+the discriminant values, everything else is undefined behaviour. Therefore,
+using a C-like enumeration in FFI to model a C `enum` is often wrong.
+
+</div>
 
 It is an error for [zero-variant enumerations] to have the `C` representation.
 
@@ -290,9 +294,13 @@ padding bytes and forcing the alignment of the type to `1`.
 The `align` and `packed` representations cannot be applied on the same type and
 a `packed` type cannot transitively contain another `align`ed type.
 
-> Warning: Dereferencing an unaligned pointer is [undefined behaviour] and it is
-> possible to [safely create unaligned pointers to `packed` fields][27060].
-> Like all ways to create undefined behavior in safe Rust, this is a bug.
+<div class="warning">
+
+***Warning:*** Dereferencing an unaligned pointer is [undefined behaviour] and
+it is possible to [safely create unaligned pointers to `packed` fields][27060].
+Like all ways to create undefined behavior in safe Rust, this is a bug.
+
+</div>
 
 [`align_of_val`]: ../std/mem/fn.align_of_val.html
 [`size_of_val`]: ../std/mem/fn.size_of_val.html

src/types.md

@@ -580,14 +580,21 @@ if the sets of auto traits are the same and the lifetime bounds are the same.
 For example, `dyn Trait + Send + UnwindSafe` is the same as
 `dyn Trait + Unwindsafe + Send`.
 
-> Warning: With two trait object types, even when the complete set of traits is
-> the same, if the base traits differ, the type is different. For example,
-> `dyn Send + Sync` is a different type from `dyn Sync + Send`. See
-> [issue 33140].
-
-> Warning: Including the same auto trait multiple times is allowed, and each
-> instance is considered a unique type. As such, `dyn Trait + Send` is a
-> distinct type to `dyn Trait + Send + Send`. See [issue 47010].
+<div class="warning">
+
+***Warning:*** With two trait object types, even when the complete set of traits
+is the same, if the base traits differ, the type is different. For example,
+`dyn Send + Sync` is a different type from `dyn Sync + Send`. See [issue 33140].
+
+</div>
+
+<div class="warning">
+
+***Warning:*** Including the same auto trait multiple times is allowed, and each
+instance is considered a unique type. As such, `dyn Trait + Send` is a
+distinct type to `dyn Trait + Send + Send`. See [issue 47010].
+
+</div>
 
 Due to the opaqueness of which concrete type the value is of, trait objects are
 [dynamically sized types]. Like all