HTML templates in V5?

[Lee Jordan]

Hi folks,

Anyone had any luck with chopping out the div tags in the search results or any luck in customizing the HTML to help clean up the markup which goes to the browser with Version 5?

I have a feeling I can do something in the CGI, but it's like going back 12 years in time for me, I'm not sure if I may break the CGI by deleting the div tags? Anyone had any luck trying to figure out which part of the CGI affects the HTML which is output for the search results?

Thanks
Lee

[oraya]

Hi folks,

Anyone had any luck with chopping out the div tags in the search results or any luck in customizing the HTML to help clean up the markup which goes to the browser with Version 5?

I have a feeling I can do something in the CGI, but it's like going back 12 years in time for me, I'm not sure if I may break the CGI by deleting the div tags? Anyone had any luck trying to figure out which part of the CGI affects the HTML which is output for the search results?

Thanks
Lee

Hi lee,

It validates fine for me. What Doctype are you using?

The only part that didn't validate for me was the form, that I copied from the template (search_template.html) into my nav bar. But that was sorted by adding some span tags, like so:

<form method="get" action="<? echo $baseaddress; ?>search/search.php" class="zoom_searchform"><span class="bottom_bar_search">Search For: <input type="text" name="zoom_query" size="20" value="" class="zoom_searchbox"> <input type="submit" value="Search" class="zoom_button"></span></form>

What part of the code isn't validating?

Oraya

PS You need to remember if you are using strict that certain attributes are deprecated. Example being height etc in tables, you need to use css to get around it, either in-line:
<table style="height: 100%;">
Or in a style sheet. Check out the w3c for more info on deprecated tags for the errors you are getting.
http://www.w3.org/TR/html4/index/attributes.html Assuming you are using html4 strict!

[Lee Jordan]

Hi lee,

It validates fine for me. What Doctype are you using?

The only part that didn't validate for me was the form, that I copied from the template (search_template.html) into my nav bar. But that was sorted by adding some span tags, like so:

What part of the code isn't validating?
Oraya

PS You need to remember if you are using strict that certain attributes are deprecated.

XHTML 1.0 Strict with no layout tables, but it's not a validation error. The wrong tags are being used for the wrong job, the div tags should not being used the way they are.

Further reading:
http://www.w3.org/TR/html401/struct/lists.html
http://www.w3schools.com/html/html_lists.asp

[oraya]

XHTML 1.0 Strict with no layout tables, but it's not a validation error. The wrong tags are being used for the wrong job, the div tags should not being used the way they are.

Further reading:
http://www.w3.org/TR/html401/struct/lists.html
http://www.w3schools.com/html/html_lists.asp

Ok with you now, for some reason I thought you were referring to html4! I was using xhtml 1. strict, but I gave up with trying to sort this out, and ended up changing the Doctype.

Oraya.

[Lee Jordan]

Ok with you now, for some reason I thought you were referring to html4! I was using xhtml 1. strict, but I gave up with trying to sort this out, and ended up changing the Doctype.
Oraya.

Same difference, but the issue is with the misuse of mark up, sure it's valid code but that's not what I'm trying to grapple with, there's no structure to it. I've played around with the CGI which is where the HTML is stored but taking the divs out causes the CGI to stop working.

[David]

I have a feeling I can do something in the CGI, but it's like going back 12 years in time for me, I'm not sure if I may break the CGI by deleting the div tags?

The CGI is a compiled binary executable. You can't edit it with a text editor. It is a compiled binary because this gives the highest level of performance.

We sell the search.cgi C++ source code if you did want to edit it and compile a custom version.

The wrong tags are being used...

While I agree that list tag could probably have been used. What we are doing now is certainly not wrong, invalid nor unstructured. Search results aren't really a list, as each result is a collection of different elements (a title, URL, description, context, date, etc..).

Lists are a natural solution where you have multiple items of the same type. e.g. just a list of URLs, or just a list of dates. But this is not the case here.

Using list tag would also make the CSS more complex and risk interfering with existing CSS already in use on the site.

So while you can make a valid argument for the use of list tags, I believe there is an equally strong argument to be made against changing what we have. Especially when significant work is required to change the status quo and the benefit to the end user of making the change is negligible.

I would also note that Google also outputs <div> tags for its search results and it doesn't seem to have negatively effected the adoption of their service.

[Lee Jordan]

The CGI is a compiled binary executable. You can't edit it with a text editor. It is a compiled binary because this gives the highest level of performance.

We sell the search.cgi C++ source code if you did want to edit it and compile a custom version.



While I agree that list tag could probably have been used. What we are doing now is certainly not wrong, invalid nor unstructured. Search results aren't really a list, as each result is a collection of different elements (a title, URL, description, context, date, etc..).

Lists are a natural solution where you have multiple items of the same type. e.g. just a list of URLs, or just a list of dates. But this is not the case here.

Using list tag would also make the CSS more complex and risk interfering with existing CSS already in use on the site.

So while you can make a valid argument for the use of list tags, I believe there is an equally strong argument to be made against changing what we have. Especially when significant work is required to change the status quo and the benefit to the end user of making the change is negligible.

I would also note that Google also outputs <div> tags for its search results and it doesn't seem to have negatively effected the adoption of their service.

Certainly not wrong dude, nothing is ever wrong in web development as there are 20 ways to achieve the same thing. There's a better way of doing what has been done, that doesn't mean what has been done is wrong. However I do feel constricted, not so much the tags used but the lack of control over which tags go out to the browser.

It's a list of items even by the way you defined above in your own words, you have described a list and it's presented as an ordered list, therefore it's illogical to not mark it up as a list. There's is a paragraph in each result, but no paragraph tags are present, rather a div tag is used, this is not structured HTML, it's using a div on the assumption that makes the CSS easier but it makes worse CSS.

Plus a screenreader can figure out how many items are in a list, if there are too many the user can choose to skip over that long list. If it's marked up as a list that's possible. Marking it up as divs means you are actually not helping that situation.

Great CSS is self documenting: p.description {} is clearly a paragraph, self documenting. "p.description a {}" is cleary a link within that paragraph .link tells me nothing about what that will target in the HTML .link could be anything so what you've done is made the CSS harder not easier to understand. Plus browsers render pages slower if it's just .link because the browser has to figure it out too.

swapping the < div class="description" > for < p class="description" > will not have any adverse affects for your product the way I see it. Using OL tags in the HTML will just require you to supply a new style set and you can run both style concepts at the same time, and ask people to copy/paste. Having adverse affects elsewhere proves you have lost control of your CSS.

It's actually a common failure I'm finding amongst many search tools, not just this one. HTML is the basic building block, it makes sense to get that bit right first, the rest clicks into place. CSS classes cannot ever be a shortcut to not writing good structure in the HTML.

[David]

Our estimate is that we have around 100,000 sites using the software. Any change, not matter how small, will effect and confuse 10,000s of people. We would be answering support E-mails for years to come as a result.

"p.description a {}" is cleary a link within that paragraph...

What you see as simple CSS, other less experienced developers see as goobly gook. This looks more complex than what we have now. And people will see it as such. And we don't want to be in a position of needing to educate the entire world about the finer points of CSS.

Plus browsers render pages slower..

I think this is hollow claim. There is no evidence that I am aware of that this significantly effects browser speed.

While you can make ideological arguments for one tag or another, unless there is a clear benefits to the end user we aren't changing it. And sufficient benefits have not been presented to justify the work and distribution change would cause. Plus you can modify our code yourself if you think it is important.

[Ray]

I'll just like to add a few words. I understand the theological ideal behind what you are proposing, but there is always a reality aspect which makes "ideal" situations less than practical.

In a perfect world, everyone would be writing well formed HTML and CSS and have a complete understanding and total grasp of the standards. But this is not so.

When browsers themselves do not implement standards consistently, and people have to often rely on hacks and workarounds; and a large number of web developers use WYSIWYG editors which create non-conformant markup, then this is the reality of the situation that you have to address.

In all cases, we look at what makes the most sense and we weigh out cost/benefit. If there is a disadvantage to the majority of users (both existing and new ones), in exchange for very little practical gain, we would favour the former.

For example:

Great CSS is self documenting: p.description {} is clearly a paragraph, self documenting. "p.description a {}" is cleary a link within that paragraph

I agree that makes sense theoretically. But in reality, most people would be adding these styles to an existing style sheet that is employed on their website. Your method causes the link to inherit attributes from the paragraph tag which most people would have already specified for laying out the plain text on their page (eg. margins, paddings, etc.). They would have to dig through their existing styles to determine this, and most would be confused as to how to change this or adapt this to also suit their search results.

The other common case is a user who has no stylesheets on their site at all, and it would be inheriting attributes from the default paragraph class as specified by the browser. In this case, it would be even more confusing, because the user has not specified any attributes for this class and they wouldn't know where or how.

They would essentially have to re-learn, and potentially re-structure the way CSS is used through out their entire site just to suit our search page! You may think of this as a long term benefit, in that people should move towards better HTML and CSS, but I can tell you for a fact, that our users would be less than pleased with us enforcing them to restructure a website "correctly" just to work with our search page.

As a matter of fact, the way our CSS and HTML came about is largely based on user feedback. People were requesting for specific, unique tags that would be completely independent of pre-existing classes and styles specified. And in reality, that method does provide the greatest level of control and flexibility.

What you are suggesting, in fact, sacrifices flexibility, compatibility, ease-of-use (for a beginner) and user error tolerance, for little more than conceptually accurate CSS, which is more confusing for the majority.