id in category list

Bloke · 2015-04-14 10:10:58

colak wrote #289985:

I can not think of one

When doing hand-coded stuff on list elements, it can be useful to do the inner portion without Txp meddling:

<txp:section_list wraptag="nav" break="ul">
   <li<txp:if_section name="about, blog"> class="static"</txp:if_section>><txp:section link="1" /></li>
</txp:section_list>

In such cases, using the spare ‘wraptag’ as the nav container makes sense to save other markup. But if you were using role then this approach wouldn’t work as there’s no native way to inject that attribute.

etc · 2015-04-14 10:17:50

I’m ok with html_id, since it’s already here, but wouldn’t introduce any additional HTML attribute. They are quickly evolving and sometimes depreciated, hard to run after.

Bloke wrote #289981:

While a built-in etc_query-style solution for adding attributes would certainly cut down on attributes, the syntax isn’t exactly end-user friendly so if we were to go that route, we’d need something simpler that could add arbitrary atts to any <tag> (HTML or Txp). Suggestions welcome.

Question of habits/education. The txp itself is not extra user-friendly from the start, I saw few sites with one page template per article! The @attr notation is quite standard in XML, but someone could have a better proposal.

philwareham · 2015-04-14 10:23:42

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.

If you can use a native HTML element [HTML5] or attribute with the semantics and behaviour you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so.

Source

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

#13 2015-04-14 10:10:58

Re: id in category list

colak wrote #289985:

#14 2015-04-14 10:17:50

Re: id in category list

Bloke wrote #289981:

#15 2015-04-14 10:23:42

Re: id in category list

#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