Đặt cược vào HTML
(catskull.net)- Khi AI dựa trên mô hình ngôn ngữ lớn lan rộng, giá trị của HTML ngữ nghĩa mà máy có thể đọc được cũng tăng lên không kém màn hình dành cho con người
- Khu vườn đóng kín của các mạng xã hội lớn cản trở việc di chuyển dữ liệu và khả năng tương tác; các nỗ lực phi tập trung như fediverse, Threads và Bluesky cũng chưa có động lực đủ mạnh để thu hút người dùng phổ thông
- HTML hiện đại đã có sẵn khá nhiều thành phần UI cơ bản cần cho ứng dụng web, như
<details>,<dialog>và nhiều loại<input>khác nhau - Tận dụng kiểu mặc định của trình duyệt và reader mode có thể giảm phụ thuộc quá mức vào CSS·JavaScript; các thẻ đúng ngữ nghĩa giúp cải thiện khả năng máy đọc và trải nghiệm nhập liệu trên di động
- Trong bối cảnh RSS vẫn còn tồn tại và các giao diện kiểu ChatGPT đang nổi lên như một cách truy cập dữ liệu, HTML có cấu trúc có thể trở thành nền tảng thực dụng hơn các giao diện xoay quanh quảng cáo
HTML như giao diện dữ liệu cơ bản của web
- Sự xuất hiện của AI dựa trên mô hình ngôn ngữ lớn đã một lần nữa làm nổi bật tầm quan trọng của HTML ngữ nghĩa
- Cốt lõi của Internet là truyền tải dữ liệu cần thiết để con người tương tác với thế giới, nhưng mức độ tự do của HTML/CSS/JavaScript cũng có mặt trái là hạn chế khả năng truy cập dữ liệu
- Mạng xã hội của các công ty công nghệ lớn trói người dùng trong nền tảng đóng thay vì các định dạng dữ liệu và API công khai, dễ truy cập
- Khả năng tương tác giữa các nền tảng trên thực tế trở nên khó khăn
- Vấn đề càng phức tạp hơn khi các công ty không muốn việc di chuyển dữ liệu trở nên dễ dàng
- Sự bất ổn gần đây của mạng xã hội đã làm tăng trở lại sự quan tâm đến các nền tảng phi tập trung như fediverse
- Threads của Meta và Bluesky do Jack Dorsey tạo ra nhấn mạnh khả năng tương tác với fediverse rộng lớn hơn
- Tuy nhiên, người dùng phổ thông thường không chọn một mạng xã hội mới chỉ vì những lý do như vậy
- Cần nhìn lại HTML như một giải pháp đã được kiểm chứng
- Trước đây phải dùng nhiều CSS để nội dung HTML trông không tệ trong trình duyệt
- Hiện nay, nhiều phần tử HTML hiện đại đã được bổ sung, cung cấp phần lớn các thành phần UI cần thiết cho ứng dụng web hiện đại
- Reader mode có thể vô hiệu hóa thời gian bỏ ra cho styling, và có thể xem đó là điều tích cực
- Thẻ đúng ngữ nghĩa cung cấp định dạng dễ đọc cho máy
- Đây là lý do mạnh hơn để áp dụng HTML hiện đại, hơn cả việc tiết kiệm thời gian thiết kế
- RSS vẫn tiếp tục tồn tại
- Các giao diện như ChatGPT cũng có khả năng trở thành cách con người truy cập dữ liệu trong tương lai
Các phần tử HTML hữu ích hoặc đáng nhìn lại
- Đáng xem qua danh sách đầy đủ các phần tử HTML trên MDN
- Các ví dụ dưới đây chỉ dùng kiểu mặc định của trình duyệt, không có style riêng
- Tùy trình duyệt, chúng có thể hiển thị rất khác nhau hoặc thậm chí không được hỗ trợ
<abbr>: phần tử bao quanh từ viết tắt- Có thể áp dụng style để nhấn mạnh
- Chủ yếu hữu ích cho khả năng đọc của máy
<datalist>: phần tử cung cấp danh sách gợi ý nhập liệu- Có thể tạo UI trông giống typeahead
- Có vẻ không có xác thực tích hợp
- Trên Safari cần đóng thẻ
option; nếu không đóng thì sẽ không hoạt động
<details>: phần tử disclosure có thể mở·đóng- Có thể dùng như một dropdown nhỏ
- Cũng có thể áp dụng styling mạnh tay
<dialog>: phần tử hộp thoại- Là phần tử tích hợp có thể mở và đóng bằng nút, form, thuộc tính và JavaScript
- Không hoàn toàn giống modal, nhưng nếu xây modal thì đáng dùng làm nền tảng
- Có vẻ được render phía trên phần tử tiếp theo
<i>và<em>- Cần biết sự khác nhau giữa hai phần tử này
<iframe>- Được đưa vào danh sách ví dụ nhưng được nói đến như một trò đùa
<input>: phần tử nhập liệu trong form- Với input, cần dùng nhãn và kiểu phù hợp
- Trên di động, hệ điều hành sẽ mở bàn phím khác nhau tùy ngữ cảnh, nên việc chỉ định kiểu input là quan trọng
- Có nhiều input liên quan đến thời gian, có thể giảm nhu cầu dùng date picker JavaScript riêng
- Các ví dụ được nêu gồm input
color,range,datetime-local
<mark>: phần tử tô sáng văn bản- Mặc định trên Safari được hiển thị bằng highlight màu vàng
<meter>: phần tử hiển thị giá trị đo- Trên Safari, tùy các tham số đã đặt, nó hiển thị bằng màu đỏ·vàng·xanh lá
- Có thể đặt giá trị
optimum - Có thể hữu ích cho demo trực quan hóa âm nhạc 60fps
<progress>: phần tử hiển thị tiến trình- Đây là thanh tiến trình HTML native có thể nhận giá trị cố định hoặc trạng thái không xác định
- Trên Safari, nó trông màu xanh lam khi cửa sổ đang hoạt động và màu xám khi không hoạt động
- Mặc định theo màu nhấn của hệ thống, và có thể thiết lập bằng thuộc tính CSS
accent-color
1 bình luận
Ý kiến trên Hacker News
Thật lạ khi nói HTML là giải pháp cho sự phụ thuộc vào hệ sinh thái đóng. Những dịch vụ đóng như vậy vốn đã dùng HTML, và cũng dùng một số phần tử ngữ nghĩa được nhắc đến cùng các thuộc tính ngữ nghĩa ARIA tinh vi hơn
Lập luận rằng các giao diện như ChatGPT là tương lai của việc con người truy cập dữ liệu cũng vậy: điểm cốt lõi của hệ thống trí tuệ nhân tạo là chúng không cần các chú thích “cho máy đọc” đặc biệt để xử lý đầu vào. ChatGPT và các mô hình kế tiếp có thể duyệt các website thông thường như con người, và nhận ra một nhóm đoạn văn là “danh sách” mà không cần markup tường minh
Điều tác giả mô tả rốt cuộc gần giống một API thông qua các phần tử ngữ nghĩa HTML. Nhưng nếu đã có API thì không cần mô hình ngôn ngữ lớn để truy cập dữ liệu tự động; một script Python bình thường dùng Beautiful Soup là đủ, lại còn có ưu điểm là chỉ chạy cục bộ
Rốt cuộc, điều phân biệt tốt và xấu là độ phức tạp triển khai. Công cụ nào cũng có thể được dùng tốt hoặc dùng dở; người mới cũng có thể gây tai nạn lớn với cưa đĩa và pin đã sạc. Một thợ lành nghề cũng có thể chọn không dùng công cụ mà gõ sang bên cạnh, tức là đi ngược lại yêu cầu kinh doanh
Những website tôi làm gần đây có khả năng tương thích tốt nhất trong số các website tôi từng làm. Tôi không còn dùng websocket, cũng không phụ thuộc vào cách JavaScript trò chuyện từng mảnh với máy chủ. Ngay cả khi tắt hoàn toàn JavaScript, vẫn dùng được khoảng 80% sản phẩm. Tôi không hiểu vì sao các lựa chọn kỹ thuật như vậy lại không phải là giải pháp cho sự phụ thuộc vào hệ sinh thái đóng
Các mô hình ngôn ngữ lớn học từ văn bản, mã nguồn, v.v., nhưng trong tình trạng thiếu thứ đáng gọi là bộ máy suy luận, liệu chúng có thể nhìn vào cây DOM và thật sự biết nó là gì, làm gì không? DOM không phải văn bản, và do là kết quả của bundling hay component hóa nên cũng khó xem là mã nguồn có cấu trúc tốt. Nghe gần như nói “mô hình ngôn ngữ lớn có thể nhìn vào một tệp .exe bất kỳ rồi tích hợp ngay lập tức”
Tôi cũng có mối quan tâm tương tự, mục tiêu là crawling và các công cụ tìm kiếm mới. Nếu phải chạy mọi trang trong trình duyệt headless trước khi lập chỉ mục, rào cản gia nhập đối với một công cụ tìm kiếm mới sẽ cao hơn nhiều
Câu đầu của bài là “Với sự xuất hiện của trí tuệ nhân tạo dựa trên mô hình ngôn ngữ lớn, HTML ngữ nghĩa trở nên quan trọng hơn bao giờ hết”, nhưng tôi nghĩ câu “Với sự xuất hiện của trí tuệ nhân tạo dựa trên mô hình ngôn ngữ lớn, HTML ngữ nghĩa trở nên ít quan trọng hơn bao giờ hết” còn dễ bảo vệ hơn nhiều
Web ngữ nghĩa đã thất bại, và Google đã thay thế nó bằng cách đổ rất nhiều tiền vào đủ loại heuristic gắn với trí tuệ nhân tạo tốt nhất thời đó. Trí tuệ nhân tạo càng tốt thì khả năng trích xuất thông tin từ những mớ hỗn độn được làm tùy tiện càng cao; nếu mớ hỗn độn đó là đủ, thì công sức con người bỏ ra cũng sẽ chỉ đến mức đó. Về nguyên tắc, cuối cùng cả web ngữ nghĩa lẫn đống heuristic đều bị trí tuệ nhân tạo thay thế
Việc ban đầu viết là LLM rồi sau đó chuyển sang thuật ngữ chung AI cũng quan trọng. Mô hình ngôn ngữ lớn không phải toàn bộ trí tuệ nhân tạo; nó chỉ là một nhánh đang nóng hiện nay, và cũng không phải nhánh nóng cuối cùng. Không nên dự báo tương lai nhiều thập kỷ dựa trên giả định rằng mô hình ngôn ngữ lớn là câu trả lời cuối cùng của trí tuệ nhân tạo
Nếu mục tiêu là các phần liên quan của nội dung được lập chỉ mục đủ tốt và lên hạng, có thể nói động lực để áp dụng hoàn toàn HTML ngữ nghĩa vẫn chưa đủ
Nếu mục tiêu chuyển từ “lên hạng” sang “khiến mô hình ngôn ngữ lớn trích xuất tối đa sắc thái và chất liệu của nội dung”, động lực dùng tốt hơn một số phần tử nhất định có thể tăng lên. Những website làm vậy có thể có ảnh hưởng lớn hơn đến đầu ra của mô hình ngôn ngữ lớn
Cảm giác như khác biệt giữa nói đủ to để được nghe thấy và nói đủ rõ để được hiểu
Tôi có nghe họ công bố trang kết quả mới có Bard, nhưng không rõ do thói quen bỏ qua quảng cáo hay do nó chưa xuất hiện ở khu vực của tôi mà tôi chưa thấy, nên chắc phải tìm thử
Trong đầu tôi vốn nghiêng về phe web ngữ nghĩa, nhưng nếu máy có thể hiểu kha khá mớ hỗn độn đó thì câu hỏi “cần gì phải cố công?” là đúng
Cũng có những dự án cho rằng đồ thị tri thức hay các tài sản dữ liệu khác có thể giúp trí tuệ nhân tạo tra cứu tri thức “đúng”. Cá nhân tôi nghĩ tốt hơn là phát triển cách để trí tuệ nhân tạo có thể tự tạo tài sản dữ liệu của nó. Trọng số của mạng nơ-ron cũng là một tài sản như vậy
Vấn đề chân lý vẫn rất khó. Làm sao cho trí tuệ nhân tạo biết một tri thức nào đó đáng tin hơn tri thức khác? Tất nhiên con người cũng gặp vấn đề tương tự
Hầu hết các phần tử HTML này tôi hầu như chưa từng nghe đến, và thấy khá tiếc. Vì những thứ như vậy có thể giúp ích đáng kể trong việc chấm dứt hệ sinh thái “cái gì cũng cần JavaScript”
Ít nhất chúng có thể đưa JavaScript trở lại gần với vai trò ban đầu hơn: một phương tiện để thêm chút trang trí hoặc tương tác. Nó không cần phải là thứ thay thế cho toàn bộ markup và là bộ quản lý DOM toàn quyền
Trình duyệt trong mơ của tôi có lẽ sẽ có dạng như visurf https://sr.ht/~sircmpwn/visurf/, với engine Netsurf bên trong được cập nhật để hỗ trợ HTML+CSS hiện đại, bao gồm cả các phần tử này. Với một trình duyệt như vậy, có lẽ có thể tạo ra một web nhỏ gần như không có JavaScript. Nó sẽ ít phá hỏng screen reader, theme hệ thống, phím tắt hơn nên khả năng truy cập tốt hơn, dùng ít tài nguyên hơn nhiều so với các bộ máy JavaScript nặng nề có thể thay thế, và dường như vẫn làm được phần lớn những gì ta kỳ vọng ở các ứng dụng web tầm trung ngày nay. Những thứ như WebGL thì có thể mở Firefox, nhưng chẳng hạn một client Matrix cũng có thể chỉ cần thêm chút JavaScript cho websocket và mã hóa đầu cuối
Khả năng mở rộng cũng hầu như không có, nên chỉ cần phải làm thứ gì hơi phức tạp là cuối cùng lại phải bỏ đi và bắt đầu lại bằng JavaScript. Khi đó thà bắt đầu bằng JavaScript ngay từ đầu còn hơn; hướng đó hoạt động tốt, cho toàn quyền kiểm soát và chạy giống nhau trên mọi hệ thống
Rốt cuộc các component bổ sung kiểu này trở thành phần phình to mà mọi trình duyệt phải triển khai nhưng chẳng ai dùng
datalisttôi đã nghĩ “ồ, đúng là thay đổi cuộc chơi”. Hành vi thì giống nhau giữa các trình duyệt, nhưng ngoại hình lại hoàn toàn tùy từng trình duyệt và không thể style bằng CSSCó lúc chỉ thấy văn bản của dữ liệu, có lúc lại thấy cả văn bản lẫn thuộc tính
value. Vì vậy bạn không chọn “Atlanta”, mà chọn “234290780 Atlanta”, tức là chọn cả ID lẫn giá trịTrong thao tác click cũng không thể lấy ngay ID, mà phải lấy toàn bộ rồi parse ID. Cảm giác như một phần tử bị bỏ mặc
Bài viết có liên kết tới MDN, và MDN là một trong những tài liệu tham khảo ngắn hữu ích nhất. Tất nhiên cũng có đặc tả WHATWG HTML, còn nếu quá đồ sộ thì có cú pháp dạng SGML DTD cho các snapshot WHATWG HTML 2021·2023 và cả cú pháp dòng HTML 5.x cũ
[1]: https://sgmljs.net/docs/html200129.html
Tôi muốn tin vào semantic web, muốn tin rằng trình duyệt có thể cung cấp các module mặc định tốt và style mặc định ổn, nhưng hiện tại đành phải chấp nhận là không phải vậy
Chỉ riêng việc gắn label cho
inputcũng đã phải nghĩ tại sao nó không phải là thuộc tính, rồi cũng khó chắc nên dùng như wrapper hay đặt làm phần tử anh em có thuộc tínhfor=. Đây chỉ là phần nổi của tảng băng. Với mỗi tag, bạn phải học cả lịch sử phát triển của nó và tra cứu lại cách đúng hiện nay là gìLẽ ra chúng ta đã có thể có thứ tốt đẹp, nhưng giờ có lẽ nên bình tĩnh và buông xuống
Chắc chắn có những chỗ kỳ lạ và góc cạnh thô ráp, nhưng nếu mọi web developer đều biết tận dụng semantic HTML tối đa, JavaScript trong trình duyệt sẽ ít hơn nhiều, lỗi accessibility cũng ít hơn, và khi đặc tả cần sửa hoặc thay thế những điểm kỳ quặc này thì có lẽ đã có nhiều con mắt chú ý hơn
Thuộc tính
labelcó lẽ sẽ mang nghĩa nội dung văn bản thuần, và như vậy trông quá hạn chếHTML, đúng như thứ đã được dùng suốt nhiều thập kỷ, có lịch sử phức tạp và nhiều lớp. Dù vậy gần đây nó không thay đổi quá lớn, và nhờ MDN, việc học đủ để biết HTML5 có thể làm gì và đào sâu thêm khi cần là khá dễ
labelsau taginput. Như vậy có thể dùng các pseudo-class CSS để chọn và style label theo trạng thái của inputDĩ nhiên, để dùng hiệu quả bất kỳ hệ thống xuất bản nào, thật ra là bất kỳ hệ thống nào, bạn đều phải học cách dùng các phần tử cơ bản mà nó cung cấp. Vì vậy đây không phải vấn đề riêng của semantic web
Tôi dùng
detailsrất nhiều để debug template HTML của GoNếu đặt dữ liệu vào khi ở chế độ phát triển bằng
{{if .DevMode}}, lúc thu gọn nó không làm hỏng trang nhiều nên không quá lộ, còn khi cần thì mở ra để xem toàn bộ nội dungdetails. Nó rất gọn gàng mà không hiểu sao lại không được dùng nhiều hơnCũng dùng được trong GitHub Markdown, và có người dùng nó cho ví dụ hoặc phần giải thích inline
Phần đọc và demo tương tác rất hay
Sau vài năm đụng đến Flutter, tôi lại đi đến cùng một kết luận. Phải đặt cược vào HTML
Tổ hợp Astro / Tailwind / Daisy UI / Alpine.js rất hợp để tạo các site HTML dùng nhiều server-side rendering đơn giản và rắc thêm một chút tính phản hồi phía client
Thành phẩm là các file HTML đơn giản, tử tế; hiển thị đẹp và chạy tốt trên trình duyệt web desktop lẫn webview bọc trên mobile. App của tôi về cơ bản là tĩnh nên được cache trên CDN, chạy được cả offline, và việc xem source giúp debug dễ hơn
Điểm hay nhất là tôi có thể tự tin rằng một lập trình viên mới, dù xuất thân từ React, Angular, PHP hay Python, chỉ cần nhìn file build 100 dòng khoảng 3 phút là hiểu. Nó thật sự đơn giản, và điều đó rất tuyệt
Tôi nghĩ vấn đề của semantic web là dù có dễ đến đâu, các lập trình viên vẫn từ chối dùng cho đúng. Extension trình duyệt của tôi dùng thẻ
mainnên tôi đã để ý kỹ thẻ này; tài liệu MDN nói rất rõ cần làm gì và chính tài liệu cũng đưa ra ví dụ sử dụng tốt. Nhưng rất ít site dùng đúngNgay cả các site chuyên nghiệp hào nhoáng cũng thường bọc toàn bộ nội dung trang, kể cả navigation, footer và những thứ tương tự, vào trong thẻ
main. Thẻ này chỉ nên dùng cho nội dung chính của trangNếu ngay cả một phần tử đơn giản như vậy còn không được dùng đúng, tôi không kỳ vọng nhiều vào các phần tử khác
Không nên giả vờ rằng những thứ này là hợp đồng
pcho đoạn văn thì theo đúng nghĩa đen là đều đã dùng đúng. Nó khác với những thứ nhưclass="card"Tôi không hiểu vì sao nhiều người có hiểu biết kỹ thuật cao lại than thở nhiều như vậy về sự vô dụng hay thất bại của semantic web. Nghe như nói “ước gì ô tô thành công, đi đường dài sẽ tiện hơn”
Nhưng đã từng có thời như vậy. Những thứ trước HTML4 phần lớn là thế, và điều đó còn tệ hơn
Vì vậy có lẽ tốt hơn là devtools đưa ra cảnh báo hoặc lỗi khi dùng sai
Thật thú vị khi nhiều bình luận ở đây xem bài này là một bài chống JavaScript. Với tôi, ngược lại, đây có vẻ là những công cụ cực kỳ hữu ích khi dùng cùng các framework lấy TypeScript làm trung tâm mà chúng ta dùng trong frontend ứng dụng doanh nghiệp hiện đại. Vì chúng là công cụ native của HTML nên không đòi hỏi quá nhiều thứ lỉnh kỉnh
Ví dụ, thẻ
metercó lẽ sẽ thay thế tất cả các module loading chúng tôi dùng trong React khi tôi đi làm hôm nay, vì nó tốt hơn nhiều so với thứ chúng tôi đang dùngCó thể tôi đã hiểu nhầm mọi người hoặc đọc sai bài viết, nhưng ngay cả trong trường hợp toàn bộ frontend gần như là TypeScript như các ứng dụng lớn ngày nay, điều này vẫn rất thú vị
Sẽ xuất hiện các ứng dụng mới có thể được tạo ra với ít JavaScript hơn rất nhiều so với trước đây. Trong các ứng dụng TypeScript doanh nghiệp hiện có, đây có thể là nâng cấp tại chỗ, nhưng hy vọng là trong phát triển app mới, ta có thể tránh được chính những framework doanh nghiệp đó. Mơ một chút thì có sao?
Tôi không muốn hoàn toàn hạ thấp phát triển web, nhưng nó thật sự kinh khủng. Tôi đã làm từ HTML thô cho đến ngôn ngữ scripting và framework trong nhiều năm, nhưng thời gian cần để làm những việc chẳng có gì to tát khiến tôi cảm thấy như một sự lãng phí chất xám khổng lồ
Khi đi nghỉ, tôi chỉ muốn tìm chỗ ăn uống hoặc nơi ghé qua trong ngày, nhưng phần lớn website đều lộn xộn, cũ kỹ hoặc không được cập nhật. Vẫn còn nhiều trang được làm một lần rồi bỏ quên. Có lẽ vì ngân sách eo hẹp nên không đủ sức cập nhật, hoặc việc cập nhật quá khó về mặt kỹ thuật
Độ phức tạp của website gây tê liệt. Thứ chỉ cần vài trang văn bản và hình ảnh đơn giản lại bị thiết kế thừa thãi, đốt vô số chu kỳ CPU. Rất có thể chúng còn được dựng bằng cách chỉnh sửa một CMS có sẵn cần cập nhật bảo mật
Gần đây tôi xem website của một rạp chiếu phim, và gần như không thể lướt qua vài bộ phim đang chiếu trong tuần đó. Tôi cảm thấy đưa vào bảng tính còn dễ đọc hơn, và thực tế khi tải JSON từ API xuống thì nó còn dễ đọc hơn thật
Phần lớn chỉ là lớp vỏ mệt mỏi, như tô son lên lợn. Một trong những lý do Facebook thành công là onboarding dễ, và một lý do khác là chia sẻ ảnh dễ. WhatsApp và Instagram cũng vậy. Xuất bản phải dễ. FTP đơn giản cũng dễ, nhưng với người bình thường thì có một sự đứt gãy kỳ lạ trong quy trình sử dụng. Mọi người muốn kéo-thả, upload, đặt đó rồi quên, chỉnh sửa dễ dàng. Những người muốn tiêu thụ dữ liệu rốt cuộc chỉ muốn phần cốt lõi. Chính là dữ liệu
Thứ mọi người muốn là một trang web được tạo kiểu tốt và có thể dùng được. Vấn đề là không có đủ nhà thiết kế trải nghiệm người dùng hiệu quả và tài năng, còn các bên liên quan trong công ty cũng thiếu cảm quan UX ổn
Vì vậy, việc chỉ cung cấp dữ liệu cốt lõi lại trở nên tốt hơn cho người dùng trung bình so với UX vụng về mà một công ty trung bình có thể chi trả. Dù không phải là điều họ ưa thích, nó vẫn tốt hơn
{UX tệ} << {dữ liệu thô} < {UX tốt}Lối đi vòng mà WordPress tìm ra là tạo các kiểu dáng và theme chuyên nghiệp rồi để người dùng mua và áp dụng. Nhưng nó không thể giải quyết cả gu thẩm mỹ tệ của các bên liên quan
Tôi cho rằng Facebook thành công vì đã áp đặt một UX chuyên nghiệp và chuẩn hóa.
{dữ liệu của mọi người} + {UX chuyên nghiệp và chuẩn hóa} = {chiến thắng}. Có thể không thích UX thời kỳ đầu của Facebook, nhưng khó có thể nói đó là sản phẩm nghiệp dư. Nhận thức chung về MySpace hay Geocities thì ngược lạiNếu muốn tìm thứ gì đó như lưới thép, tôi sẽ hỏi trước trong các nhóm WhatsApp của mình, nhóm gia đình, khu phố, bạn bè cấp ba. Thường tôi sẽ nhận được vài số điện thoại, rồi liên hệ với nhà cung cấp dịch vụ qua WhatsApp để có thông tin mới nhất
Những nhà cung cấp dịch vụ đó không thể kham nổi một website được cập nhật. WhatsApp còn có tính năng đưa catalogue vào hồ sơ, dành cho tài khoản doanh nghiệp miễn phí
Thứ tôi muốn thấy là một kiểu “Wix Widgets”. Tức là các widget kết nối dữ liệu, có mức tùy biến kiểu nối tới các lệnh gọi REST service và ánh xạ điểm dữ liệu sang phần hiển thị của widget. Nó sẽ khá hữu ích để xử lý nhu cầu website nội bộ mà công ty nào ngày nay cũng có
90–95% trang web thật sự cần giải pháp đơn giản
Có lẽ đây chính là bản chất của GUI. Có thể cấu trúc của nó là phải ra từng chỉ thị một, tiêu tốn nhiều chu kỳ, và nếu không như vậy thì không thể hoạt động đa nền tảng
articlevàsectionTất nhiên, mã HTML thô ngay từ đầu có lẽ cũng không được tạo ra để ai ngoài lập trình viên đọc, nên cũng có khía cạnh đó
Tôi đã rất hào hứng khi nghe tin có modal HTML thuần, nhưng thất vọng khi biết không có cách kích hoạt nó nếu không dùng JavaScript. Với HTML thuần thì chỉ có thể đóng, không thể mở
https://github.com/whatwg/html/issues/3567
Phần tử
dialoglà một bổ sung tuyệt vời và tôi vui vì nó đang được triển khai, nhưng một số chức năng cốt lõi lại phụ thuộc vào JavaScript. Để mởdialog, phải dùng JavaScript đặt thuộc tínhopenSẽ thật tốt nếu có cách để phần tử
buttonhoặcamở hộp thoại. HTML đã có tiền lệ về tương tác trang được tích hợp sẵn. Ví dụ, liên kết có thể cuộn trang, phần tửdetailscó thể ẩn phần tử sau một tương tác, nên việc một phần tử khác trên trang có thể mởdialogcũng có vẻ tự nhiênVí dụ, hãy thử nhấp vào dấu
?ở góc trên bên phải tại đây: https://aavi.xyz/proj/colors/onclick