ジョブを細かく分けてGitHub Actionsのテストを効率化する
改善戦略 実行のタイミングやGitHubの状況や依存サーバーのネットワークの状況によって変動はあるものの、早くて7分、だいたい10分〜15分くらいかかっている。早いか遅いかは、他の開発と比べても内容や状況が違うのでなんとも言い難いが、個人的な感想としては「遅い」。というより、一切の工夫をしていなかったので、もっと早くできるはずだと考えた。 ビルドされたファイルを複数の環境で共有する 処理全体の中で時間がかかっている処理は3つ。 依存パッケージのインストール ビルド テスト さらに、課題の一つとして「テスト実行時に開発用依存パッケージ（devDependencies）がインストールされているせいでテストが失敗しない問題がある」というものがあり、これを処理に追加しないといけない。 開発用依存パッケージのインストール ビルド 依存パッケージを一旦すべて削除 本番用依存パッケージのインストール テ
【仕様の読み方】HTMLの要素をどうやって学ぶか
<search>要素がHTML Standardに追加されました。私も初めて出会う要素になるわけですが、とても良い機会なので、私が要素を調べる際にどうやって調べて学んでいるのかを共有したいと思います。これは新しい要素に限らず、既存の要素の調査に応用できると思います。また、初学者はもちろん、マークアップを生業としている方にも参考になると思います。 新要素追加の経緯を調べる まずはHTML StandardのGitHubのPRからスタートするとよいでしょう。議論や更新はGitHubで行われています。たとえば、今回の<search>はAdd the <search> element #7320というPRによって更新されました。 そもそも更新自体のキャッチアップ方法はクローズされたPRを更新順にして確認してもいいですし、更新のみをツイートしている@htmlstandardのTLを確認してもいいと思
<dialog>内でautofocus属性がほぼ必須になる話
HTML Standardの更新でdialog要素に関する変更があったので、自分の理解の整理のためにもまとめてみます。 Scott O'Hara氏によるdialog initial focus, a proposalという提案の一部が反映された変更で、#8199でマージされました。主な変更差分を見るとわりと大きめの追記がされていることがわかります。 提案されていることがすべて採用されていたり、提案で言及されている問題がすべて解決しているわけではなく、議論が続いているものも多いので、今後dialog要素がどういった方向に変更され、進化していくのかを見守る補助的な記事になればいいなと思います。 autofocus属性ほぼ必須 結論から言うと、autofocus属性がほぼ必須となります。そのautofocus属性はdialog要素自体とは限らず、内包している子孫要素に適切な場合もあります。 <d
WAI-ARIA中級編 ロールの決まり方
前回の「WAI-ARIAを学ぶときに整理しておきたいこと」（以下、「前回の記事」と略）やYouTubeで生配信した「WAI-ARIA勉強会」で 要素には暗黙のロールをもつ role属性を使うことでロールを上書きできる 要素によって上書きできないロールがある と説明した。 しかし、上書きできないロールをrole属性で指定してしまったときに最終的にロールが何になるかの説明をしていなかったし、要素の条件次第によっては上書き可能なはずのロールが無効化されたり、ロールが変化したりすることに触れていなかった。今回はそこが仕様でどうなっているのか深堀りしてみたいと思う。 ロールの決定に影響するもの まず、簡単にロールがどういったものから決定されるのかをざっくりと最初にまとめる。 要素の種類（HTMLとしてのセマンティック） 属性 構造（先祖・子孫関係） これをまず念頭に置いて、仕様を読みすすめると理解が
markuplintを開発し始めて5年経った
現在の数字 最新バージョン: v2.10.1 コミット数: 2,122 IssueとPull Request: 530件（クローズ含む） npmダウンロード: 11,179（週間） テストコード数: 916 テストカバレッジ: 74% GitHubスター: 315ユーザー スポンサー: 1ユーザー ふりかえり ライトニングトークでのお披露目 最初のコミットから約4ヶ月後、VS Code拡張も用意できて業務でもドッグフーディングしてある程度機能するようなったので、開発の動機と楽しんで開発できている旨をライトニングトークした。SNSを中心にそこそこ広まってくれたのもあって、GitHubのスターが増えたり、「使ってみよう」という声をぼちぼちと聞くようになった。最初のアピールとしては良い滑り出しだったとは思う。 当然ながらスライドは日本語だしSNSの広がりも国内にとどまったので、GitHubのスタ
フォーカスアピアランスの達成基準についての考察
2.4.7 では基本的に「フォーカスインジケータが見えること」で適合となります。失敗例もインジケータを視覚的に完全に消していることのみとなっており、「十分な達成方法」や「さらに対応が望まれる達成方法」として『目立つ』という言葉をつかっているものの、その具体的な閾値は示されていませんでした。それが今回の 2.7.11 と 2.7.12 では、具体的な数値や計算方法が『面積』や『カラーコントラスト』で規定されることになります。 面積とコントラスト まずは原文を読み解いてみます。 Success Criterion 2.4.11 Focus Appearance (Minimum) (Level AA): When user interface components receive keyboard focus, an area of the focus indicator meets the
WAI-ARIAを学ぶときに整理しておきたいこと
結論 ロールについて知る HTMLの暗黙のロールを知る ロールを知った上でロールに対して使用できるプロパティ/ステートを使う (おまけ) markuplintを使おう aria属性を使う前に まず、いきなりaria-labelやaria-selectedとかに手を出さない。 aria-selectedとかを発見してしまうと「option要素以外にもselectedみたいな意味を付加できるんだ！すげえ！使ってみよう！」みたいな気持ちが沸き上がってしまう。わかる。とってもよくわかるよ。当時ぼくもそうだったから。 ただ、そこはぐっと我慢してほしい。 なぜかと言うと、aria属性は、使っていいときと悪いときがある。きちんとWAI-ARIAという仕様と、ARIA in HTMLやCore Accessibility API Mapping (Core-AAM)という仕様で決められていっている[1]の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Popover API - JavaScript不要、HTMLのみでポップオーバーUI