id in category list

gomedia · 2015-04-14 10:37:10

Bloke wrote #289981:

But I’m not altogether comfortable with attribute bloat like this …

Is that really a problem? After all CMSs exist to create web pages, and what we should be aiming for is a system that enables us to create websites with the minimum amount of messing around and the maximum amount of code readability as possible. And to have some tags with various inconsistent permutations of wraptag/class/html_id is a pain.

No wraptag for <txp:title />? Really?

I know I’ve banged on about this before but I’m all in favour of a bit of brutal consistency – for example, all tags that generate HTML code should automatically have wraptag/class/html_id.

And one could argue that, in this day and age, there should be a “role” attribute for all as well.

Anyway, here endeth the moan!

Bloke · 2015-04-14 11:05:08

gomedia wrote #289989:

to have some tags with various inconsistent permutations of wraptag/class/html_id is a pain.

I agree up to a point. But therein lies the rub. We already have inconsistent uses of the same attribute. For example, <txp:images> and a few other imagey tags:

html_id The HTML id attribute applied to the wraptag, if set, otherwise to the img tag.

Compared with <txp:search_input>:

html_id The HTML id attribute assigned to the search form.

And now <txp:category_list> and <txp:section_list>, which will read something like:

html_id The HTML id attribute assigned to the wraptag. Ignored if wraptag not used.

The class attribute is similar. Some have defaults, some don’t. Some attach to the inner element if wraptag is omitted, some don’t.

To a large degree, Txp’s attribute defaults have strived to be about common sense, i.e. they should do what you expect most of the time (yes there are maddening exceptions that have been introduced over the years for various reasons).

Under the common sense rule the implementations above mostly work, because if you don’t supply a wraptag, it’s wholly reasonable to expect the HTML id to attach itself to the inner element, if there’s only one. In the case of lists, well, you can’t have the same ID on all inner items so pushing the id verbatim onto your break items (if indeed you’re using break) is going to create invalid markup. So we either ignore the attribute or append some counter or something. Not sure which is the most intuitive. Thoughts?

id is kind of a special case because it’s widely used, accepted and supported in HTML and CSS for targeting the DOM. Other attributes, yes, we could support if they make sense, but trying to cater such attributes to a spec with the longest development cycle in the history of the Internet (and no nailed-down implementation in sight) is like returning to the riverside from an invigorating swim to find someone’s run off with your clothes.

gomedia · 2015-04-14 12:52:18

I vote for ignore.

GugUser · 2015-04-14 16:56:34

philwareham wrote #289988:

Just a side note, you don’t need to specify a role="navigation" on a nav tag anymore, since that is the default semantic role for that tag anyway.

I also wanted to write this. And see this latest article by html5doctor.com

etc · 2015-04-16 08:29:25

I shouldn’t have said role :)

Textpattern CMS

Textpattern CMS support forum

#16 2015-04-14 10:37:10

Re: id in category list

Bloke wrote #289981:

#17 2015-04-14 11:05:08

Re: id in category list

gomedia wrote #289989:

#18 2015-04-14 12:52:18

Re: id in category list

#19 2015-04-14 16:56:34

Re: id in category list

philwareham wrote #289988:

#20 2015-04-16 08:29:25

Re: id in category list

Board footer