セレクター設定のコツ - 階層を少なくする

UI要素を取得した際のセレクターを適切に設定すると、ウェブサイトが更新されてもエラーにならず目的のリンクをクリックする等が可能となる。前々回と前回でそれぞれセレクターの値設定の演算子を「含む」に変更する方法と不要な指定をしない方法を確認した。つづいて3つめに階層を少なくする方法を確認する。

セレクターの値設定の演算子を「含む」に変更する方法と不要な指定をしない方法についてはこちらをご参照。

前々回と前回と同じくMSNのサイトのニュース欄のひとつのニュースをUI要素として取得する。このようなセレクターが自動取得される。

f:id:yujihb:20211106003310j:plain

前回のようにセレクターを精査して不要なものを削除した結果、以下のようにclassの文字列等の条件が少ないセレクターを作ることができる。

f:id:yujihb:20211107015728j:plain

ここでさらに階層を少なくする方針を考える。上記例ではmainから始まって10段階の階層になっていることが分かる。この階層は一部省略することができ、それによってさらに変化に強いセレクターにすることができる。

セレクタービルダーの左ペインのすべての階層にチェックボックスがあり、ここでセレクターに含めたい階層と省略したい階層を選ぶことができる。例えば試しに一番上とその次の階層を省略してみる。

f:id:yujihb:20211115223801j:plain

次に上記のセレクターでウェブページ上のUI要素をクリックできるか、ブラウザーで目的のサイトを開いてテストする。その結果問題なくクリックできることがわかった。さらにどこまで省略できるか極限まで試したみたところ、MSNのウェブページのニュース欄の1つ目のニュースは「a[Class="contentlink"]」のみでクリックできることがわかった。

f:id:yujihb:20211115224320j:plain

最小のセレクター指定「a」も試したが残念ながら別のものをクリックしたので使えず、Class="contentlink"の指定だけは必要だった。このような少ない指定で問題なくクリックできたのは、このウェブページ上で一番最初に登場するClass="contentlink"を持つタグ「a」が偶然にニュース欄の1つ目のニュースであったためだ。たまたまである。

上記はすこし極端な例だったが、前回のclass等の属性の指定削除と同様に、このようにして階層についても不要なものを削除することができる。これにより上位の階層が一部増えたり無くなったり変化したとしても、クリックするリンクの周辺の階層構造が保たれている場合にはエラーなくクリックすることができる。

ただし条件指定が少ないということは目的物を特定できない状況になりやすくなる。簡潔にしすぎると目的ではないものをクリックしてしまうし、条件を指定しすぎるとクリックできずエラーとなる。最適にセレクターを設定するには、どちらか極端でなく中庸に中ほどを狙って指定をするバランス感覚が必要となろう。

セレクター設定のコツ - 要素が一つだけの階層でclass等を指定しない

UI要素を取得した際のセレクターを適切に設定すると、ウェブサイトが更新されてもエラーにならず目的のリンクをクリックする等が可能となる。前回はひとつの方法としてセレクターの値設定の演算子を「含む」に変更する方法を確認した。つづいてもう一つ。要素が一つだけの階層でclass等を指定しない方法を確認。

そのほかのコツはこちらをご参照。

前回と同じ例でMSNのサイトのニュース欄のひとつのニュースのリンクをクリックするためのセレクターを考える。

f:id:yujihb:20211106003310j:plain

前回確認したようにclass等が想定しない文字列に変わってしまうとクリック等ができなくなる。そのためclass等の文字列の指定を可能な限り少なくすると変更に強くなる。目的物を特定するために不要な指定がもしあればその指定を削除したい。不要なものを確認するためまずはウェブページの構造を確認する。

自動取得されたセレクターでは、以下の緑下線のdiv classやli classをもれなく指定して目的のリンクを特定していた。

f:id:yujihb:20211106003354j:plain

不要なものの典型的な例は、タグが一つしか無い階層の条件指定だ。一つしか無いのでclassの文字列の条件を指定する必要がない。

例えばセレクターの一番下の階層の「a」の周辺部分の階層をHTML内で確認すると、ひとつ上の階層の「li」の中に「a」のタグは一つしか無いことが分かる。したがって自動取得されたセレクターの一番下の「a[Class="contentlink"]」は不要な指定をしており、ここは「a」だけ指定されていればよい。以下のようにセレクタービルダーで該当する階層のClassの「使用済み」のチェックボックスを外せばOK。

f:id:yujihb:20211107010313j:plain

 

もう一つ上の階層の「li」の周辺の階層を確認する。タグ「ul」の中に複数の「li」が並列で存在することが分かる。タグが一つしか無い状況と異なり、目的物が入っている目的の「li」を特定するために条件を指定する必要がある。

f:id:yujihb:20211107011358j:plain

まずはclass等の属性で条件指定できないか確認する。すべての「li」が同じclass名でありこれでは特定ができない。data-idは互いに異なる連番の値のため利用できそうであるが、data-idが「209」から始まる理由がわからずウェブページが更新された場合にどのように変化するか想像し難いため利用しないほうがよい。classなどの属性で条件指定することは難しそうなので、これはあきらめてセレクタービルダーでclassなどのチェックボックスを外した方がよい。

classなどの属性が特定に使えないので、ここは並び順でシンプルに指定することにする。そのためには属性Ordinalに数値を設定すればよい。Ordinalを0に設定すると一番最初の「li」を指定できる。Ordinalを1に設定すると2番めの「li」を指定できる。この「ul」の階層のなかの「li」は実際にはMSNのウェブページ上に並んでいる各ニュースに対応しており、ウェブページ上の1つ目のニュースのリンクをクリックするにはOrdinalは0を設定すればよい。

 

f:id:yujihb:20211107014444j:plain

Classなどの属性の指定が無く、並び順だけが指定された「li:eq(0)」がセレクターに設定された。eqの括弧の中身が並び順である。「li:eq(0)」は一番最初の「li」、「li:eq(1)」は2番めの「li」を指定する。

このように一つ一つ階層を確認して行き不要なものをすべて精査した結果、最初と同じリンクが以下のセレクターで指定できることがわかった。余分なclassの指定がなくなって見た目もシンプルに、変化に強いセレクターとなった。

f:id:yujihb:20211107015728j:plain

 

セレクター設定のコツ - 演算子「含む」に変更する

UI要素を取得した際のセレクターを適切に設定すると、ウェブサイトが更新されてもエラーにならず目的のリンクをクリックする等が可能となる。ひとつの方法として、セレクターの値設定の演算子を「含む」に変更する方法を確認。

以下の記事のようにMSNのサイトのニュース欄のひとつのニュースをUI要素として取得する。

するとこのようなセレクターが自動取得される。

f:id:yujihb:20211106003310j:plain

mainから始まってdivなどなどたくさんの階層の値が指定されている。ウェブページが更新されてもしdivのclass等の名称がこのうち一文字でも変わったりするとクリックができなくなる。classが特定の文字列と「等しい」といった厳しい条件を複数指定しているためだ。わずかな変更にも弱い状態である。変更に対してもう少し強く柔軟にするためには、セレクターの値指定の演算子を「と等しい」ではなく「含む」とするとよい。

例えば下から2階層目の「li」には「Class="hdlist  primary"」と指定されている。自動取得されたセレクターをよく確認してみるとなんとhdlistとprimaryの間に半角スペースが2つ入っている。サイト運営者がいつ半角スペース一つに更新してもおかしくない。脆弱である。

f:id:yujihb:20211106023741j:plain

ここでビジネス要件やウェブページ管理者の気持ちを強くイメージする。そしてなかば勘で更新が少なそうな、変化しなさそうな文字列にあたりをつける。例えば「primaryを含む」という条件に変更する。

f:id:yujihb:20211106025151j:plain

演算子「含む」に変えることでセレクタービルダーの下部にあるセレクターも変わる。演算子「と等しい」は「=」、演算子「含む」は「*=」になる。

これでもし半角スペース一つに更新されたとしても問題なく対象を指定することができる。「primaryを含む」にしたのであるから、もちろんclassを「hdlist secondary」などに更新されると動かなくなる。その場合は「hdlistを含む」という条件のほうが今後はよさそうであることが分かる。時間はかかるが、エラーに遭遇し修正を繰り返していくとウェブページ更新の方向性や更新されやすい箇所が少しずつわかってきてさらに適した方法で設定できるようにもなる。ただこれは受動的すぎるかもしれず、もしかしたらウェブページの作り方の詳細を知っているともっと適切な指定方法を選んでいけるのかもしれない。