@@ -2100,7 +2100,7 @@ <h3>Processing Capabilities</h3>
2100
2100
< var > validated first match capabilities</ var > .
2101
2101
</ ol >
2102
2102
2103
- < li > < p > For each < var > first match capbilities </ var > corresponding
2103
+ < li > < p > For each < var > first match capabilities </ var > corresponding
2104
2104
to an indexed property in < var > validated first match capabilities</ var > :
2105
2105
< ol >
2106
2106
< li > < p > Let < var > merged capabilities</ var > be the result of
@@ -2239,15 +2239,15 @@ <h3>Processing Capabilities</h3>
2239
2239
</ ol >
2240
2240
2241
2241
< aside class =note >
2242
- < p > The algorithm outlined in < a > matching capabilities</ a > blithely
2243
- ignores real-world problems that make implemention less than
2244
- perfectly straightforward, particularly since capbilities can
2245
- interact in unforeseen ways.
2246
-
2247
- < p > As an example, an implementation could have a capbility that gives
2248
- the path to the browser binary to use. This could cause
2249
- both < code > browserName</ code > and < code > browserVersion</ code > to be
2250
- impossible to match against until the browser process is started.
2242
+ < p > The algorithm outlined in < a > matching capabilities</ a >
2243
+ blithely ignores real-world problems
2244
+ that make implemention less than perfectly straightforward,
2245
+ particularly since capabilities can interact in unforeseen ways.
2246
+
2247
+ < p > As an example, an implementation could have a capbility
2248
+ that gives the path to the browser binary to use.
2249
+ This could cause both < code > browserName</ code > and < code > browserVersion</ code >
2250
+ to be impossible to match against until the browser process is started.
2251
2251
</ aside >
2252
2252
2253
2253
< p > When < dfn > matching capabilities</ dfn >
0 commit comments