Eh? Eh wot? Why? Last I recall I'd managed to get rid of the crappy SMF-esque spans there, since they weren't useful or desirable. Now it seems they're back. What's the reason for their reappearance?
you mean the part <span class="button_title">? they're needed for the responsive part where the text is hidden and a font Icon is shown.. I wasn't able to find a simple solution without the spans..
Ah. K. That sorta makes sense. It'd be possible to do it without them, but it'd need pseudos anyway.
(one way to do it would be to use negative text-indent to hide the text and apply the font icon on the pseudo element)
ETA: Meh, Scrap that. Wouldn't work so well for a row of buttons coz the anchors would overlap. Works a treat for solo stuff.
'Course the other trick would be to set font colour the same as the button background, with fixed size and hidden overflow on the anchor. That way you wouldn't see the text and wouldn't need a span. :)
ETA: I see you're using display: none; on the title at the moment. I know SFA about the specific details of a11y on mobile, but I do know that blind and partially sighted peeps use mobiles. General principles have always been that it's better to hide such text from sighted users without hiding it from screen readers, and display: none; hides it from screen readers
If the text was just coloured to match the button background and choppped at overflow, no worries. Pseudo just sits on top.
yeah, I've experimented with changing colors (transparent) and font-size, too.. IIRC it caused issues with margin, the size of the button and such things.. Feel free to share the code you have in mind, I gave up at some point and switched to the (easier) solution, just to have a working version.
If there's a better solution which also works for screen readers with audio output I'd be happy :)
K, I'll have a play with it and see if I can get it to work. What I'm thinking is fixed width on the anchor and hidden overflow, along with the colour trick. If it works it will be easy to implement. I can't see why it wouldn't work, but will test it to make sure.
Ant, I know you hate git, but there's two options that might help.
1) gist.github.com that will let you create pastebin style pastes without creating a whole repo. It has version control and other people can edit/fork from your gist. You can add multiple files in a single gist and name them so people know where they go.
2) github now has on-page editing. You can edit from the page and it will create a commit and pull-request. You can't screw it up because you're editing directly from the repo.
So you could start with a gist of the original files, save it, then paste the edits. It will show changes. Then TE can see what you did without you having to go "find this line" "replace it with" "find this line" "add this and this and this after it"
Ok, sounds like a plan.