[Proposal] new author element HTML


#1

I think HTML 5.2 should be added new element <author> … where author represents author of creative work. Because for now nearest value for <author> have <cite> element. But <cite> it not fully represent semantic for most often cases.

For example how would it be (think it would be perfect):

<p><author>Sergei Smirnov</author> who wrote <cite>Yesterday, Tomorrow</cite> was
winner <abbr>Palme d'Or</abbr> festival</p> 

More example how would it be (think it would be perfect too):

<p><author>Mazda</author> build new turbo engine called <cite>Bird3000</cite> with 
perfect fuel consumption</p>

New element could be help differentiate element. Because what we have now uses only :

<p><cite>Sergei Smirnov</cite> who wrote <cite>Yesterday, Tomorrow</cite> was winner 
<abbr>Palme d’Or</abbr> festival</p>

-last example imho, really strange


Proposal for <text> tag
#2

Just for reference, I’ll copy this over from MDN:

It’s worth noting that the W3C specification says that a reference to a creative work, as included within a <cite> element, may include the name of the work’s author. However, the WHATWG specification for <cite> says the opposite: that a person’s name must never be included, under any circumstances.

It would be nice to at least see agreement between the W3C and WHATWG, as they’re literally incompatible.


#3

WHATWG could use element <author> too with note “person’s name must never be included, under any circumstances.” So for WHATWG <author> could be everything but no person name.


#4

Is there any reason that you can’t do this today with a custom element, write about it, promote it and see if you can’t get use (and proper use)? I’d suggest that this is the mostly likely path toward actually getting an element added to a standard (and that that’s a good thing).


#5

Today no one custom element can’t get use like can <author>. It was surprised for me, when I read about <cite> element. It have many examples, but noone can’t get author’s name for creative work. But for any creative work always have own author. Now what can do HTML if talk about creator and his result - creative work:

<p><cite>Sergei Smirnov</cite> who wrote <cite>Yesterday, Tomorrow</cite> was winner 
<abbr>Palme d’Or</abbr> festival</p>

But it’s badly experience, because no difference about author and creative work (2 fully differents substation and same element <cite> ). So semantic’s like to say:

<cite>Yesterday, Tomorrow</cite> who wrote <cite>Yesterday, Tomorrow</cite> was 
winner <abbr>Palme d’Or</abbr> festival</p>

#6

Today no one custom element can’t get use like can <author>. It was surprised for me, when I read about <cite> element.

The cite element has always been so underspecified that it’s more or less useless.

The Dublin Core metadata provides for a link to a page about the author or creator(s) of a Web page. As so often with Web metadata it’s not always easy to distinguish between

  • a link to a page about the author
  • a link to a page about the person who transcribed or edited the text
  • a link to the author’s home page
  • a URI that’s actually a surragate for the author, not necessarily in any way canonical
  • a broken link :slight_smile:
<p><cite>Sergei Smirnov</cite> who wrote <cite>Yesterday,

Tomorrow was winner Palme d’Or festival

It would perhaps be nice to indicate whether Yesterday, Tomorrow here is a screenplay or a book that inspired a film or a book or a play…

Adding an “author” element baerly scratches the surface. For example, what about an editor? Or a painter?

But being precise might be too much to ask for HTML.


#7

I think HTML is the wrong place to solve this, there’s far too many useful metadata fields you could subdivide into and different use cases will have different models. It’s more rightly the place of various semantic schemas such as http://schema.org/, the cite element works well as a high level element to contain all this relevant information.

I do agree that the the W3C and WHATWG need to sort it out with their conflicting specs and I’m heavily leaning towards the W3C on this one, without far more indepth semantics specifying cite and the useful subcomponents of it it seems completely out of left field to put such a specific but related exception on it.


#8

If what you’re trying to say is simply “no non-standard thing has the same advantages of a standard thing”, of course. If what you’re trying to say is “it can’t get significant use” - why? Lots of non-standard things get use, even over their standard counterparts. Why? Often because we didn’t do a great job at the standard one in the first place and they don’t meet the needs many developers actually have. "Yes, of course, so we should do a better job at defining <author> is what I expect you’re thinking - but many of those elements involved years of discussion and debate trying really hard to do a good job.

When it comes to an element that is mostly about semantics, this is in some ways even trickier because semantics are only valuable if they are used properly. If people misuse them in practice, their value as intended goes out the window. Take <address> for one example. It was the subject of a lot of discussion and the specs said for years said ‘it is X, not Y’ - but in practice, a ton of people used it for Y - so what is it? Ultimately, the spec had to be changed. There’s a good model for definitions of terms, a dictionary. In many languages (english, for example) words aren’t “invented” by a committee, they become widely understood before they are formalized and given that extra boost as a standard word. The stated aims of most standards are to pave the cowpaths - this is kind of the same thing…

It’s within our power to tread some new cowpaths and custom elements allow us a way to do that if what you think is the answer involves element-ness as slang. If there is no additional function or ‘feature’ here, you don’t even need to define it with JavaScript - just start get people to start using it in their markup. The browser has always allowed non-understood elements and custom elements simply provide a plan that doesn’t hose future standards. If you can get people to use it, and prove that it is used as intended, then it’s very easy to standardize without debate. Convincing people is way way way easier than getting a standards committee to agree too.

Of course, there’s definitely a possibility that elementness isn’t going to be advantageous enough get uptake any more than something else that’s out there already trying to do some of this.


#9

“editor or painter” - no, because author is most common uncategorized term. What is dublin core? I talk about native HTML. Now problem have for element without new element, because HTML document have strange semantic without new element instead to be explicit clear.

It would perhaps be nice to indicate whether Yesterday, Tomorrow here is a screenplay or a book that inspired a film or a book or a play…

oh yes, in this context talking about book. But globally it doesn’t matter, because new element can exact indicate author of creative work. Now semantic, if it right semantic, can represents only creative work or only author of creative work (but it’s bad experience when what represents authror same reperesent creative work). However, although or author of creative work or creative work is possible inside document (probably with poor semantic), but and author and ceative work (too often case) have too badly semantic without understanding what is author of creative work and what is creative work.

<p><author>Sergei Smirnov</author> who wrote book <cite>Yesterday, Tomorrow</cite> was
winner <abbr>Palme d'Or</abbr> festival</p>

#10

I think HTML is the wrong place to solve this, there’s far too many useful metadata fields you could subdivide into and different use cases will have different models. It’s more rightly the place of various semantic schemas such as http://schema.org/, the cite element works well as a high level element to contain all this relevant information.

oh no, schema it’s not native. Today too much differents especially not specifications (specification in specification in specification and so on). For help web progress it should be used maximum native HTML and try don’t use unnative technoligies as it possible.


#11

If what you’re trying to say is simply “no non-standard thing has the same advantages of a standard thing”, of course. If what you’re trying to say is “it can’t get significant use” - why? Lots of non-standard things get use, even over their standard counterparts.

No no, you are not understand main problem about <cite> element. It can not exict without element <author> (author functionality). Yes, now it exist but it have break semantic. So why is it needed especially today, when peoples want quality? So element <cite> or must be remove at all or HTML creators should be added new semantic element <author> which fully represent clear explicit and prefect semantic. It must be done (remove <cite> or HTML creators should be added new semantic element <author>) because HTML specification can’t solve those problem. It’s like about <sub> and <sup> elements, but if deleted one of it (for example <sub>)… and <sup> meaning after delete what mean and “sub” and “sup”.

If there is no additional function or ‘feature’ here, you don’t even need to define it with JavaScript - just start get people to start using it in their markup.

What are you talking about? I telling about clear native standard without mistakes. And for now in 2018 <cite> element still have bad semantic without new element <author>. And new element will made HTML standard more clear for <cite> element.

Here is two examples, which is fully show about clear semantic with <author>: Example1:

<p><author>Sergei Smirnov</author> who wrote book <cite>Yesterday, Tomorrow
</cite> was winner <abbr>Palme d'Or</abbr> festival</p> 

And example2:

<p><author>Mazda</author> build new turbo engine called <cite>Bird3000</cite>
with perfect fuel consumption</p>

Example how it works now (no semantic difference about author and creative work):

<cite>Sergei Smirnov</cite> who wrote book <cite>Yesterday, Tomorrow</cite> was
winner <abbr>Palme d'Or</abbr> festival</p> 

So semantic like this:

<cite>Yesterday, Tomorrow</cite> who wrote book <cite>Yesterday, Tomorrow</cite> was
winner <abbr>Palme d'Or</abbr> festival</p> 

or like this:

Yesterday, Tomorrow who wrote book Yesterday, Tomorrow was winner Palme d'Or festival

Those last 3 examples above like if for <dl>, <dt> and <dd> remove one of themselves.

Normal semantic:

<dl>
  <dt>Blanco tequila</dt>
  <dd>The purest form of the blue agave spirit...</dd>
  <dt>Reposado tequila</dt>
  <dd>Typically aged in wooden barrels for between two and eleven months...</dd>
</dl>

Semantic if remove <dt>:

<dl>
  <dl>Blanco tequila</dl>
  <dd>The purest form of the blue agave spirit...</dd>
  <dl>Reposado tequila</dl>
  <dd>Typically aged in wooden barrels for between two and eleven months...</dd>
</dl>

Semantic if remove <dt> and <dd>:

<dl>
  <dl>Blanco tequila</dl>
  <dl>The purest form of the blue agave spirit...</dl>
  <dl>Reposado tequila</dl>
  <dl>Typically aged in wooden barrels for between two and eleven months...</dl>
</dl>

#12

Several people, myself included, have argued in favor of an element type, e.g. n or name or person, for making up proper or person names over the course of the last 20 or 25 years. It makes sense for indexing, styling and translating. I doubt that more specific element types like author make more sense. Somehow it always got shot down because allegedly nobody would use it (correctly).


#13

Let’s me ask you to clarify one thing: what is the effect that you believe this should have? That is, let’s say you could write your author tag today. What should happen, as you say, ‘natively’? Does it look special without author styling? Does it ‘do’ something? Or does it just mean ‘this contains the name of the author’ so that something (not the browser, natively) analyzing the markup can identify it and do useful things?


#14

For example, browser could display the author’s name like how Firefox currently extracts it in Reader mode from the <meta name="author"> element. Search engines or other external tools could use the semantics too.

And for what it’s worth, the rel="author" attribute of a link has similar semantics already used at least by Google: it adds the author’s name after the page title in search results.


#15

It builds on top of native though. HTML has done its best when defining high level and structural elements, its biggest mistakes have been attempts to define content semantics (like our friends cite and address), the needs of this level of semantics do not match up well with HTML.

HTML by its nature will never be able to capture the fine grained detail these semantics need without a plethora of new elements, will inevitably get some things wrong or incomplete and almost certainly add in weird requirements that authors will ignore. Just taking a look at schema.org shows you how complex these sorts of definitions need to be. On top of that different semantics are required for the same/similar information in different contexts depending on use cases.

Document semantics and content semantics are fundamentally separate concerns and HTML has generally messed up when it’s tried to cross that boundary.


#16

@chaoaretasty
Yes, I’m greed with you about it’s mistake add elements like <cite> and <address> in HTML.

IMHO, I think older elements ( <em>, <i>, <mark>, <u> and <cite>) should be deprecated as have similar meaning for other elements (all they just represents more or less <b> and <strong> elements, where <strong> - great important meaning and <b> not important meaning) and almost unused.

But why those elements still in HTML in 2018? if they are removed then there will be no need for <author> element. But if <cite> still in HTML, <author> must be in HTML too for clear semantic. Because <cite> without <author> keep break implicit semantic.


#17

It have only one effect - fix error for <cite> element, which keep break semantic alone. So, for clear explicit semantic of <cite> element or HTML creators must be remove himself <cite> element or should be added new semantic element <author> (for using with <cite> element)


#18

You talk about link. But <author> element for <cite> element, which is not link. So instead <cite> it could be <a> or <link> element. So, or HTML creators must be remove <cite> element or should be added new semantic element <author> (for using with <cite> element) for clear explicit semantic.


#19

I mean, having any new semantics means things can do new things with it, obviously - but many tags in HTML ‘do’ something - they create new DOM APIs, they load things, they provide information in the accessibility tree, they are interactive, etc. The reason I am asking is because the thing about elements where we’re just creating a thing you can then maybe potentially look up and do something useful with, but otherwise is just effectively like a span for all other purposes - this is the easiest path to blaze. You don’t need standards, or even JavaScript or CSS - you just need to go try to convince people that it’s worth using your slang and show that they do it appropriately. Why? Well, as you can see here there are only a few people and a lot of ‘x would be better’ or ‘you can already do z’ - and this will only be exponentially multiplied in standards.

10 years is a not atypical time to standardization. Do you want to wait 10 years to see any benefit? If you use slang, you can get much of the benefit now. If your slang picks up, standardization doesn’t have to be years, then it’s just science: We already know people get it, appreciate it and use it.


#20

I mean, having any new semantics means things can do new things with it, obviously - but many tags in HTML ‘do’ something

i refuse to accept that HTMl is trying to be a semantic document language when it doesn’t even have a “poem” element!

What i expect from a cite element is a bibliographic reference, or, a link to a bilbliography in what i’m reading [BL89a], basedon the academic concept of citations. So we’d need authors (junior and senior), editors, publisher, city, year, title, series-title, volume, pages, and all the other things that e.g. refer and bibtex support. It’d be relatively easy to add these as rel values, or to use class attributes and do something on schema.org, and there may be some value in this.

But possibly it woudn’t affect as many people as being able to mark up song lyrics and mention performers, composers, lyricists/songwriters, record labels, concert hall designers, and so forth.

Even working out how to represent an author’s name isn’t trivial - using the same element for Japanese and French people means dealing with firstname/lastname ordering issues for example.

10 years is a not atypical time to standardization. Possibly not but even W3C moves faster than that. People’s names are notoriously tricky to get right, but at least there’s some prior art.