html

The issues were fixed actually. https://github.com/whatwg/html/wiki/dialog--initial-focus,-a... https://github.com/whatwg/html/pull/8199

> I don't think anyone would say web-standards are excellent, well designed and well-managed. and yet: > I don't want to care about the latest flavor of frontend insanity. Those not well managed, not well-designed and not-well managed standards somehow get a pass because that insanity is now a part of the browser? Do you know that Chrome argued that <dialog> should be removed from the platform because it's a bad API with multiple issues? https://github.com/whatwg/html/pull/4184#issuecomment-440405...

About two years year before <dialog> was rushed into all browsers, it had been implemented only in Chrome, and Chrome devs suggested removal of <dialog> completely. Reason? No consensus on multiple issues relating to accessibility and security: https://github.com/whatwg/html/pull/4184#issuecomment-440405... And then boom! It was shipped everywhere with none of the issues discussed or fixed. Why? My tiny conspiracy theory is because browsers are hellbent on removing "legacy" APIs like confirm/prompt, and Chrome tried to remove it about half-a-year to a year before <dialog> was suddenly shipped everywhere: https://dev.to/richharris/stay-alert-d

https://github.com/whatwg/html/issues/3577#issuecomment-2329... and the links inside appear to imply there's interest?

All I can find is a Chrome experiment. Do you have a draft spec available? Edit: Found a link to the Chrome blog which in turn links to https://github.com/whatwg/html/issues/9799 Initial question remains however, how are we to properly distinguish the user interface actions?

> Who is in charge of these HTML changes? This is horrible. We all are, so thank you for this horrible proposed-but-not-yet-implemented change! Jokes aside, you can participate in the discussion yourself here: https://github.com/whatwg/html/issues/10520 But be warned, you will probably not be able to convince people with just "Please, just no!". > I get the sense that the people currently working on HTML and CSS are front-end designers and not programmers. Yeah, that makes sense, it's a markup language, not a programming language. The targeted audience for HTML and CSS is way bigger than just programmers. For the people who want to build imperative UIs or even "immediate mode" GUIs there are a ton of options out there already. I get the sense that people complaining about HTML/CSS not being like a programming language enough are programme

There‘s also some work to be able to indicate these rules via an HTML attribute but the work is a bit stalled. https://www.stefanjudis.com/today-i-learned/safari-allows-to... https://github.com/whatwg/html/issues/3518 Another cool feature Apple spearheaded was the ability for websites to indicate the change password page in standard manner: https://w3c.github.io/webappsec-change-password-url/

That’s ironic. Firefox once had scoped CSS which no one else picked up, so it was removed. Now it’s the last mover. https://caniuse.com/style-scoped https://github.com/whatwg/html/issues/552

> handling case insensitivity in Unicode bug for bug compatible with email providers. The official email standards basically say to treat email addresses as a binary format. You aren't even allowed to do NFC / NFD / NFKC etc normalization. https://github.com/whatwg/html/issues/4562#issuecomment-2096... Unicode has some standards which are slightly better, but they're only for email providers to restrict registering new email addresses, and it still doesn't suggest case-insensitivity. https://www.unicode.org/reports/tr39/#Email_Security_Profile... I'm tempted to write an email standard called "Sane Email" that allows providers to opt into unicode normalization, case insensitivity (in a well-defined way), and sane character restrictions (like Unicode's UTS #39). Currently the standards allow for pretty much _any_ unicode characters, includi

The only way to get out of the current front end hell IMO is if we get client side import: https://github.com/whatwg/html/issues/2791

There's this HTML spec issue for an include feature that I think could always use more support: https://github.com/whatwg/html/issues/2791 One of the things said in there is that they look for usage of userland solutions. I mentioned in another comment, but there are custom elements that do client-side includes, like: https://www.npmjs.com/package/html-include-element

> but architecturally they're inadequate for solving the problems modern frameworks and libraries address Such as? Do you think these are inherent limitation? Is it possible to get to an "adequate" place with webcomponents alone? Or with web component based frameworks or libraries? > that's why you see them used nearly nowhere Little companies you have have heard of using webcomponents extensively: YouTube, many Google properties, GitHub. Personally I'm hella sad that this industry doesn't make new js frameworks like they used to. It now takes a Microsoft or a Facebook's name recognition for people to pay attention. And where-as before many people tried, devs in the React age see themselves not as capable web makers, but as downstream React craftsmen; we don't recognize in ourselves that we create & shape our development experience, are l

I don't agree as I have converted all the modals/dialog in my web app to <dialog> and boy it has been a breeze. A few killer features: - Goodbye z-index, since the last opened dialog always get's promoted to the top in #top-layer [1] - Free focus handling, it doesn't trap focus inside dialog but that's kinda opinionated anyway [2] - styling and animation is EASY with `@starting-style` and `allow-discrete` and can even use view-transitions [3] Here's a basic sliding in drawer with blurred background I have in svelte: <style> dialog::backdrop { backdrop-filter: blur(4px); } /* IS-OPEN STATE / dialog[open] { translate: 0 0; } / EXIT STATE / dialog { transition: translate 0.2s ease-out, overlay 0.2s ease-out, display 0.2s ease-out allow-discrete; translate: 384px 0; } / 0. BEFORE-OPEN STATE */ @starting-st

Very nice to see some progress here. I think "CSS Ruby Annotation Layout Module Level 1" saw most work around 2013/2014, there are also specifications for ruby that are part of XHTML and HTML 5 standards. Even when ruby markup is popular with south-east asian scripts I mostly want to use it for interlinear text or textspan-level inline annotations for a software to learn languages. I remember with the ruby specified in XHTML standard there were ergonomic issues when ruby is written, i.e. it's nice for interlinear text markup to not have to close HTML tags. Also there were issues where people did not understand what the differences between mono ruby, group ruby and jukugo ruby is (correct me if I remember it wrong). Ruby seems to be not implemented well in browsers, some ruby-related tags were deprecated, the specification posted is part o