コンポーネントベース（別名プルベース）のWebフレームワーク（Tapestry、Wicketなど）を使用している場合、マークアップがW3C検証に合格したことをどのように判断しますか？2つのアプローチが思い浮かびます。
実行中のアプリをクロールする
プロ：
- 検証に必要なすべてのマークアップがページに存在します。
短所：
- すべてのページとすべてのケースをヒットするのは非常に複雑になる可能性があります。
- 何かが間違っている場合、どのコンポーネントが問題を引き起こしているのかが明らかでない場合があります（特に大規模なアプリの場合）。
- 同じコンポーネントを何度も検証している可能性があります（作業の重複）。
- ページ/コンポーネントが多い場合は、非常に長い時間がかかる場合があります。
HTMLテンプレートをオフラインでクロールする
長所：
- 各コンポーネントを検証する必要があるのは1回だけです。
- 問題を見つけた場合は、どのコンポーネントが問題を引き起こしているのかを正確に知ることができます。
短所：
私が考えることができる短所のほとんどは、ページの完全なマークアップがないため、コンポーネントのコンテキストを失うことを含みます。
- 特定のコンポーネントのDOCTYPEがわからない場合があります。
- コンポーネントの親が何であるかを知るのは難しい場合があり、問題を引き起こす可能性があります。
<span>たとえば、ブロックタグ（eg<form>または）を含むインラインタグ（eg）の無効なケースを検出します<p>。 - これらのタイプのフレームワークのHTMLテンプレートには、多くの場合、検証されない無効な属性と特別な記号（通常はフレームワークに何かを示すため）が含まれています。
したがって、問題は、コンポーネントベースのアーキテクチャを使用している場合、マークアップをどのように検証するかということです。これを行うための推奨されるテクニック、またはさらに良いツールはありますか？
編集：これに対する答えがこれ以上なかったことに少し驚いています。コンポーネントベースのフレームワークを使用するときにマークアップを検証することは珍しいですか？それとも、それらを使用している人はあまりいないのでしょうか。