-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Definitions in headings are visually unrecognizable #425
Comments
That's a definition, but valid point. I wonder if we should solve the styling issue or instead attempt to move definitions out of headings as generally that seems like bad practice to me. |
I think definitions in headings is fine, and the fact that it's not obvious that they're definitions is also fine? The point of definitions is to have something to link to; they don't need to be visually obvious, IMO. |
The point is that Moving these definitions out of the headings could be one possible way of addressing this, and could probably also address whatwg/html#9811. |
Yes, there are a number of interactable elements in HTML which are not properly marked up. It'd be nice to add some stuff to our build tools to emulate what Bikeshed (the other major spec build tool) does to them, which is add a little floating |
I don't know what you mean by "little floating |
They have different markup which sometimes helps (and sometimes does not), but for this they appear to have the same problem: https://fetch.spec.whatwg.org/#should-response-to-request-be-blocked-due-to-mime-type? |
For example the heading of section 13.2.6.5 of the HTML spec is rendered as:
what you cannot see is that "foreign content" is
hyperlinkedclickable.The text was updated successfully, but these errors were encountered: