Opened 6 years ago

Last modified 3 years ago

#9988 confirmed Task

Stop using <a> for everything.

Reported by: Danil Owned by:
Priority: Low Milestone:
Component: UI : Toolbar Version: 4.0
Keywords: Discussion Cc:

Description

What's reason to use <a> element with javascript: pseudo hrefs?

I think we should use <button>'s for buttons. Why not? Or at least <span>'s. Same with context menus.

Change History (11)

comment:1 Changed 6 years ago by Jakub Ś

Status: newpending

Sorry, I have by accident pressed 'invalid' instead of 'request info'


@danya_postfactum In short this is about a11y.

  1. CKEditor supports also older browsers in which only links are focusable. This is the reason we use them a lot.
  2. As you probably know not everyone is using mouse. There are some people using keyboard and screen readers.
  3. NOTE: there are problems with styling buttons in Safari.

Could I ask if this was just general note (like hey let's change something) or you have perhaps more detailed ideas how can this be overcome? Id yes I really would like to read them :).

Last edited 6 years ago by Jakub Ś (previous) (diff)

comment:2 Changed 6 years ago by Danil

I'm sure you know about tabindex attribute . What's wrong with it?

How old browsers should we support? IE5.5? Really?

Links without hrefs - strange, hacky, oldschool way. Google uses either buttons or divs(spans) with tabindex="0"

I personally always kept looking unwittingly when my browser pops link up at the bottom corner when I hover a link. It's annoying when this link is fake...

comment:3 Changed 6 years ago by Jakub Ś

I will need to recheck (on Safari Mac and win) this but contrary to tabIndex property - http://www.w3schools.com/jsref/prop_html_tabindex.asp, tabindex attribute doesn't seem to be supported in Safari - http://www.w3schools.com/tags/att_global_tabindex.asp.

comment:4 Changed 6 years ago by Wiktor Walc

Keywords: Discussion added
Status: pendingconfirmed

button indeed seems to be a more appropriate element for... a button :)

How old browsers should we support? IE5.5? Really?

Almost.. IE in quirks (we have no control over the environment where the editor is used).

We'd rather not change it immediately, but I'll leave the discussion opened because the ticket makes sense (a relatively simple change may require lots of additional potential changes and definitely testing).

comment:5 Changed 6 years ago by Danil

We'd rather not change it immediately

I agree.

Excuse me, where can I find current browser support info? http://dev.ckeditor.com/wiki/Compatibility is outdated...

comment:6 Changed 6 years ago by Wiktor Walc

Browser support is explained here:

http://docs.ckeditor.com/#!/guide/dev_browsers

(we're in the process of moving everything related to V4 to that newsite)

comment:7 Changed 6 years ago by Piotrek Koszuliński

Priority: NormalLow

I know that using links as buttons may not be semantically correct solution, but I believe that if they were chosen, there were reasons for that. I don't know them. because I'm working on CKE too short, but here are my guesses:

  1. A11y - JAWS and other screen readers have to correctly understand the meaning of button.
  2. Styling - I remember that there were problems with styling buttons (especially on Safari and older Chrome).
  3. Focus and selection handling. And here I mean not only possibility to focus a button or link, but also what happens with selection in editable.

And even if now we could switch to buttons I don't think we'll risk that. There's no point in spending so much time only to make things a little bit more semantic, when there's so much to lose.

I'll keep this ticket, but set priority to "Low".

comment:8 Changed 5 years ago by Danil

TinyMCE 4 uses buttons. I like CKEditor, but it becomes too inert...

comment:9 Changed 5 years ago by Piotrek Koszuliński

You haven't proved that we do something wrong, so I guess we're inert in the right direction. That was a joke of course, but the truth is - what harm does the links cause? Do you think it's really worth spending weeks on changing them into buttons, breaking backwards compatibility, just for a sake of making a change? I don't think so. We believe that there are more important things to work on right now and we allocate our limited resources on these things. If we worked on details like buttons vs links there could never be ACF, widgets and lots of other features which other editor don't have. As I wrote, links cause no problems and when we will have spare resources we will move them into more important bugs and features.

Additionally, we're shifting our resources to CKEditor 5, which will be a total rewrite. We are at the beginning of a design phase, so there's little interesting resources yet and no dedicated webpage, but if you're interested, then take a look on https://github.com/ckeditor/v5-protos/issues. We would be grateful if you could report issues for things that you think should be done differently in CKE5.

comment:10 Changed 3 years ago by Marek Lewandowski

As note here: <span> elements would be still a wrong choice for button. The best correct element for this purpose is <button>.

comment:11 Changed 3 years ago by Marek Lewandowski

#14684 marked as a duplicate. It refers to using semantic elements for buttons instead falling back to ARIA markup.

Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy