It is confusing that textarea and input have different placeholder attributes, and only input's appears in the TOC

[denis-sokolov]

Please correct me if this is an incorrect place or form for submitting issues. It seems the repository is new and I could not find any guidelines.

Since d534237, placeholder attribute of textarea elements can contain newlines. (W3C version still forbids newlines. There is an open bug about it.)
However, the specification still mentions the prohibition of newlines in the section on placeholder and does not mention an exception: html.spec.whatwg.org, developers.whatwg.org.

In addition, the version at html.spec.whatwg.org directly links from the section on textarea to the misleading section on placeholder.

(It seems I got very tired looking at all specs and my previous observations are mostly incorrect.)

The common section on placeholder in the spec, the one that shows up if I search on developers.whatwg.org for placeholder, forbids newlines and mentions no exceptions for textareas. Perhaps a note is in order?

It took me a while to figure all this out, it was considerably confusing.

[domenic]

(Thanks for reporting! You got it right.)

I can't find the prohibition on newlines that you mention in the textarea section... Could you quote the confusing text? In fact I see the opposite:

All U+000D CARRIAGE RETURN U+000A LINE FEED character pairs (CRLF) in the hint, as well as all other U+000D CARRIAGE RETURN (CR) and U+000A LINE FEED (LF) characters in the hint, must be treated as line breaks when rendering the hint.

Note that the textarea placeholder attribute is different from the input placeholder attribute, so if you are looking at the input section, that's not the right place to go.

In addition, the version at html.spec.whatwg.org directly links from the section on textarea to the misleading section on placeholder.

Hmm. When I click that link, then click the "placeholder" link, I get to the textarea placeholder attribute section, which as mentioned above doesn't have a prohibition and in fact has the opposite.

Let me know what I'm missing...

[denis-sokolov]

My apologies. It seems I got very tired reading through different specs and I got confused.

I retract most of my statements but one: the common section for placeholder mentions no exception for textareas and that's the section that's much easier to find right away, including navigating to developers.what.org, and typing in placeholder in the search box in the top right. Perhaps a short note about the exception is in order.

The scope of this issue is now considerably smaller than I first thought, so feel free to close with no further comment.

(It seems this is the place that I started with and where I assumed that WHATWG spec also forbids this. Later I got confused between different sections of the spec and looked at the general section, while providing correct links in the issue. Sorry.)

[domenic]

Can you direct me to the common section for placeholders? I see separate sections for input and and for textarea, but no common section.

[denis-sokolov]

You're embarassing me further. :) Yes, it's the inputs section.

My point was that I don't have a clear distinction between inputs and textareas. Yes, textarea happens to use a different tag name, but for all intents and purposes, inputs, texteareas, and selects are the same for me. I always consider those to be interactive "inputs" sharing many attributes (name, readonly, placeholder, and others), and the different tag names to be only a historical artifact. If you disagree, consider input[type=radio]. :)

So, that said, if I take a look at the table of contents of the Forms, I see the placeholder being mentioned only in the 4.10.5.3.10. and it's a section common for all inputs and it includes all the things I've expected to see, like readonly, required, and so on. In addition, as I said previously, if I search for "placeholder" on developers.whatwg.org, that's the section that shows up.

Now I realize that the actual section that's common to all form controls is "Attributes common to form contorls", and I was mistaken. However, I do still believe that a input[type=text] has more in common with a textarea than with input[type=radio]. More behavior, and yes, more attributes.

So perhaps my confusion and my GitHub issue is a bit more, after all, it's about improving grouping different form elements. From their current "by a meaningless historical element name" to "by their actual usage and properties".

[domenic]

Hmm. There really is a clear distinction between inputs and textareas, though. They are processed differently in a substantial number of ways. I don't think we want to start conflating them. You may consider input type="text" and textarea conceptually closer than input type="text" and input type="radio", but in terms of parsing rules, browser implementation internals, and spec text, the opposite is true. inputs have certain attributes and properties; textareas don't. input's placeholder attribute is simply different from textarea's placeholder, similar to link's sizes vs. img's sizes.

The table of contents issue is interesting, but really it's just a reflection of the fact that we don't have a section for every attribute. The "Common input element attributes" sections and "Attributes common to form controls" are exceptions. But if you're looking for e.g. option's disabled attribute you'll also be disappointed that it doesn't show up in the TOC>

Issues with developers.whatwg.org's search are another thing too... that hasn't been updated in a long time, and perhaps needs its own repo. It's kind of a separate project, although for now there's nothing wrong with reporting bugs on it here. Maybe that's the action item, is to make their search more aware?

[denis-sokolov]

You're right, I should stop looking at the spec as an HTML author, it's for browsers and implementation details instead of semantic abstractions are meaningful here. Then perhaps it's only the developers.whatwg.org that's misleading, as that is directly targeted at HTML authors.

[domenic]

Closing this since it's not really actionable on our side. But when developers.whatwg.org gets updated, we should be sure to check that typing "placeholder" in the search box shows search results for both---probably by making sure the search autofill includes all attributes, not just those defined by headings.